<br><font size=2 face="sans-serif">Alan, Mike</font>
<br>
<br><font size=2 face="sans-serif">Thanks for the feedback. Here is latest
version that addresses all comments except where noted below. The biggest
changes are:</font>
<br>
<br><font size=2 face="sans-serif">- Trimming & padding are now part
of the 'extraction' & 'insertion' phases, and not conversion.</font>
<br><font size=2 face="sans-serif">- Complex element separated from simple
element</font>
<br><font size=2 face="sans-serif">- Simple type / local element / global
element distinctions called out</font>
<br><font size=2 face="sans-serif">- Repeat properties pulled forward into
own phase</font>
<br>
<br>
<br>
<br><font size=2 face="sans-serif"><b>Notes:</b></font>
<br>
<br><font size=2 face="sans-serif">1) Mike - I agree that dfdl:inputValueCalc
and dfdl:outputValueCalc should <i>not</i> be allowed in dfdl:format
annotation (ie, scoping). Spec & xsds should be updated.</font>
<br>
<br><font size=2 face="sans-serif">2) Mike - you say that escape schemes
are needed when looking for initiators - we should discuss - I'm not sure
this is a real requirement in practice - I've never come across this.</font>
<br>
<br><font size=2 face="sans-serif">3) Mike - the DFDL parser/unparser is
driven by <i>model position</i> - not by infoset position - you only get
elements in the infoset. </font>
<br>
<br><font size=2 face="sans-serif">4) Mike - I don't think that dfdl:initiatedContent
is needed when unparsing.</font>
<br>
<br><font size=2 face="sans-serif">5) Alan - encoding and byteOrder do
apply for sequence, choice and any, because there could be markup involved.
</font>
<br><font size=2 face="sans-serif"> </font>
<br><font size=2 face="sans-serif">6) Alan - lengthKind = 'pattern' - is
this something that we should support on complex elements - assumed so
for now. </font>
<br>
<br><font size=2 face="sans-serif">Regards<br>
<br>
Steve Hanson<br>
Programming Model Architect<br>
WebSphere Message Brokers<br>
Hursley, UK<br>
Internet: smh@uk.ibm.com<br>
Phone (+44)/(0) 1962-815848</font>
<br><font size=1 color=#800080 face="sans-serif">----- Forwarded by Steve
Hanson/UK/IBM on 13/05/2009 10:25 -----</font>
<br>
<br><font size=2 color=blue face="Arial">My markup on this attached - mostly
using comment balloons on the side.</font>
<br><font size=3> </font>
<br><font size=3> </font>
<br><font size=3> </font>
<p><font size=2 color=#000080 face="Arial"><b>Mike Beckerle | OGF DFDL
WG Co-Chair | CTO | Oco, Inc.</b></font><font size=2 color=#808080 face="Arial"><br>
Tel: 781-810-2125 | 100 Fifth Ave., 4th Floor, Waltham MA 02451
|</font><font size=3> </font><a href=mailto:mbeckerle.dfdl@gmail.com><font size=2 color=#808080 face="Arial"><u>mbeckerle.dfdl@gmail.com</u></font></a><font size=2 color=#808080 face="Arial">
</font>
<p><font size=3> </font>
<br>
<p>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>Alan Powell/UK/IBM</b></font>
<p><font size=1 face="sans-serif">11/05/2009 16:57</font>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td><font size=1 face="sans-serif">Steve Hanson/UK/IBM@IBMGB</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td><font size=1 face="sans-serif">dfdl-wg@ogf.org, dfdl-wg-bounces@ogf.org</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">Re: [DFDL-WG] DFDL: Action 027 - rework
of property precedence - plus issues
arising</font><a href=Notes://D06ML070/802563ED00496501/38D46BF5E8F08834852564B500129B2C/A8E87C0B6800A4E9802575B0003120E5>Link</a></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br><font size=2 face="sans-serif">Steve</font>
<br>
<br><font size=2 face="sans-serif">Comments</font>
<br>
<ol>
<li value=1><font size=2 face="sans-serif">I don't think the tables answer
the precedence of padding, escaping and encoding that we had when discussing
escape schemes. On parsing it should be remove padding, remove escape characters,
apply encoding. On unparsing it is the reverse but the tables look the
same.<br>
I think the difficulty is that escape scheme is used for identification
and extraction but also during conversion.</font>
<li value=2><font size=2 face="sans-serif">I don't think the core properties
(inputvaluecalc, etc) apply to sequence, choice or any.</font>
<li value=3><font size=2 face="sans-serif">xxxPadKind is checked
before xxxPadCharacter, xxpadxxx</font>
<li value=4><font size=2 face="sans-serif">Calendar-binary. binaryCalendarFormatRef
is only used when binCalRep = packed or bcd</font></ol><font size=2 face="sans-serif"><br>
Alan Powell<br>
<br>
MP 211, IBM UK Labs, Hursley, Winchester, SO21 2JN, England<br>
Notes Id: Alan Powell/UK/IBM email: alan_powell@uk.ibm.com
<br>
Tel: +44 (0)1962 815073
Fax: +44 (0)1962 816898<br>
</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">From:</font>
<td><font size=1 face="sans-serif">Steve Hanson/UK/IBM@IBMGB</font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">To:</font>
<td><font size=1 face="sans-serif">dfdl-wg@ogf.org</font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">Date:</font>
<td><font size=1 face="sans-serif">08/05/2009 17:24</font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">Subject:</font>
<td><font size=1 face="sans-serif">[DFDL-WG] DFDL: Action 027 - rework
of property precedence - plus issues
arising</font></table>
<br>
<hr noshade>
<br>
<br>
<br><font size=2 face="sans-serif"><br>
I've created a separate property precedence for each schema object that
can carry non-scoping DFDL properties (attached for review).</font><font size=3>
<br>
<br>
</font><font size=2 face="sans-serif"><br>
The following issues were noted:</font><font size=3> <br>
</font><font size=2 face="sans-serif"><br>
1) Missing property dfdl:textBooleanJustification - similar properties
exist for string, number and calendar types.</font><font size=3> <br>
</font><font size=2 face="sans-serif"><br>
2) What is the rule when the same DFDL properties occur on a xs:simpleType
and a xs:element that uses that type? Does this work a) like element/group
references (ie, properties combined with element winning) or b) like complex
element and its sequence (ie, element and simpleType are considered separate
objects)? I don't think section 10 covers this case. </font><font size=3><br>
</font><font size=2 face="sans-serif"><br>
3) Should we allow the DFDL nil & default control properties on a simple
type? xs:nillable and xs:default are element only attributes in xsd.
Spec currently allows this.</font><font size=3> <br>
</font><font size=2 face="sans-serif"><br>
4) Should we allow DFDL occurs properties on global elements? Whether
something repeats is a particle thing. Spec currently allows this. (IBM's
WTX and MRM don't allow this).</font><font size=3> <br>
</font><font size=2 face="sans-serif"><br>
5) Missing work item to get BiDi properties into shape and incorporated
into spec. Should these be grouped, like escape scheme, calendar scheme,
etc? Do they apply to calendar and number types?</font><font size=3> <br>
</font><font size=2 face="sans-serif"><br>
6) Should dfdl:integerBooleanXXXRep be renamed dfdl:binaryBooleanXXXRep
?</font><font size=3> <br>
</font><font size=2 face="sans-serif"><br>
7) We might want to reconsider the name of the new flag dfdl:initiated
- it could be read that the xs:sequence itself is initiated rather than
its children. </font><font size=3> <br>
</font><font size=2 face="sans-serif"><br>
8) Should dfdl:initiated also apply to xs:choice?</font><font size=3> <br>
</font><font size=2 face="sans-serif"><br>
9) Draft 33 property precedence had dfdl:outputLengthCalc - but that is
not in the spec anywhere else?</font><font size=3> <br>
</font><font size=2 face="sans-serif"><br>
Regards<br>
<br>
Steve Hanson<br>
Programming Model Architect<br>
WebSphere Message Brokers<br>
Hursley, UK<br>
Internet: smh@uk.ibm.com<br>
Phone (+44)/(0) 1962-815848</font><font size=3><br>
</font><font size=2 face="sans-serif"><br>
</font><font size=3><br>
</font>
<hr><font size=2 face="sans-serif"><i><br>
</i></font>
<p><font size=2 face="sans-serif"><i>Unless stated otherwise above:<br>
IBM United Kingdom Limited - Registered in England and Wales with number
741598. <br>
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU</i></font><font size=3> </font>
<p><font size=2 face="sans-serif"><br>
</font><font size=3><br>
<br>
</font><font size=2 face="sans-serif"><br>
[attachment "Property Precedence 034.doc" deleted by Alan Powell/UK/IBM]
</font><tt><font size=2>--<br>
dfdl-wg mailing list<br>
dfdl-wg@ogf.org<br>
http://www.ogf.org/mailman/listinfo/dfdl-wg</font></tt>
<p>
<p>
<br><font size=2 face="sans-serif"><br>
</font>
<br><font size=2 face="sans-serif"><br>
</font>
<hr><font size=2 face="sans-serif"><br>
<i><br>
</i></font>
<p><font size=2 face="sans-serif"><i>Unless stated otherwise above:<br>
IBM United Kingdom Limited - Registered in England and Wales with number
741598. <br>
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU</i></font>
<p><font size=2 face="sans-serif"><br>
<br>
</font>
<br>
<br><font size=2 face="sans-serif"><br>
<br>
</font>
<br><font size=2 face="sans-serif"><br>
</font>
<hr><font size=2 face="sans-serif"><br>
<i><br>
</i></font>
<p><font size=2 face="sans-serif"><i>Unless stated otherwise above:<br>
IBM United Kingdom Limited - Registered in England and Wales with number
741598. <br>
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU</i></font>
<p><font size=2 face="sans-serif"><br>
<br>
</font>
<br>
<br><font size=2 face="sans-serif"><br>
</font>