<br><font size=2 face="sans-serif">This is where Suman and I left it on
the array prefix issue.</font>
<br>
<br><font size=2 face="sans-serif">The problem is where do you stop with
creating special "occurs" versions. You can in principle have
an "occurs" variant of almost every property.</font>
<br>
<br><font size=2 face="sans-serif">...mikeb</font>
<br>
<br><font size=2 face="sans-serif">Mike Beckerle<br>
STSM, Architect, Scalable Computing<br>
IBM Software Group<br>
Information Platform and Solutions<br>
Westborough, MA 01581<br>
direct: voice and FAX 508-599-7148<br>
assistant: Pam Riordan <br>
priordan@us.ibm.com
<br>
508-599-7046<br>
<br>
</font>
<br><font size=1 color=#800080 face="sans-serif">----- Forwarded by Mike
Beckerle/Worcester/IBM on 11/20/2007 10:02 AM -----</font>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>Suman Kalia/Toronto/IBM@IBMCA</b>
</font>
<p><font size=1 face="sans-serif">11/16/2007 11:53 AM</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">Mike Beckerle/Worcester/IBM@IBMUS</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">Fw: DFDL array prefix</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br><font size=2 face="sans-serif">Mike - The proposed grammar productions
seem correct to me..</font>
<br>
<br><font size=2 face="sans-serif">I see your view point and your concern
for bifurcation of properties and I do agree that it introduces level of
redundancy. I guess the choice boils down to having extra level of redundancy
(dummy sequence) in the logical model or having redundancy in DFDL properties
and each alternative can be justified and supported with good arguments.
>From consumability perspective having clean and less/no extra level of
redundancy in the logical model is preferred because it would be
at the user face all the time while the DFDL properties pertaining to occurrences
will be rare and only for specific use cases. From pure DFDL spec
perspective, having no redundancy in DFDL properties is desirable.</font>
<br>
<br><font size=2 face="sans-serif">May be we can go with the conservative
approach as you mentioned ie not add the extra production in
the grammar for Array for now but add an appendix in the document listing
the alternative for overcoming redundancy in the logical model and how
the revised grammar would look like. We can get more feedback when the
document is reviewed by IBMers (architects, implementers, UCD) and folks
in the standards community. </font>
<br>
<br><font size=2 face="sans-serif"><br>
Suman Kalia<br>
IBM Toronto Lab<br>
WebSphere Business Integration Application Connectivity Tools <br>
Tel : 905-413-3923 T/L 969-3923<br>
Fax : 905-413-4850 T/L 969-4850<br>
Internet ID : kalia@ca.ibm.com</font>
<br><font size=1 color=#800080 face="sans-serif">----- Forwarded by Suman
Kalia/Toronto/IBM on 11/16/2007 10:34 AM -----</font>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>Mike Beckerle/Worcester/IBM@IBMUS</b>
</font>
<p><font size=1 face="sans-serif">11/16/2007 10:17 AM</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">Suman Kalia/Toronto/IBM@IBMCA</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">DFDL array prefix</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<p><font size=2 face="Arial">Here's the proposal I think:</font>
<p>
<p><font size=2 face="Arial">Array = ArrayPrefix ArrayContent</font>
<p><font size=2 face="Arial">ArrayContent = [ Element [ <b><i>OccursSeparator</i></b>
Element ]* [ <b><i>OccursSeparator</i></b> StopValue] ]</font>
<p><font size=2 face="Arial">StopValue = SimpleElement</font>
<p>
<p><font size=2 face="sans-serif">I'd suggest the keyword occursLeadingSkipBytes
is the property which controls the ArrayPrefix content. </font>
<p>
<p><font size=2 face="sans-serif">My argument against this is a slippery-slope
argument. This starts us down the path of having a bifurcation of
many properties into an occurs and non-occurs flavor. E.g., once you add
the above, then by analogy why not have these additional keywords which
apply to the array as a whole, not the elements of it:</font>
<p>
<p><font size=2 face="sans-serif">occursAlignment</font>
<p><font size=2 face="sans-serif">occursAlignmentUnits</font>
<p><font size=2 face="sans-serif">occursInitiator</font>
<p><font size=2 face="sans-serif">occursTerminator</font>
<p><font size=2 face="sans-serif">occursLength</font>
<p><font size=2 face="sans-serif">occursLengthKind</font>
<p><font size=2 face="sans-serif">occursLengthUnits</font>
<p>
<p><font size=2 face="sans-serif">All of this is avoided by simply requiring
an extra sequence to provide these same format characteristics using the
ordinary non-occurs keywords, and that's very preferable to me to this
proliferation of occurs and non-occurs variants. </font>
<p>
<p>
<p><font size=2 face="sans-serif">...mikeb</font>
<p>
<br>
<br><font size=2 face="sans-serif">Mike Beckerle<br>
STSM, Architect, Scalable Computing<br>
IBM Software Group<br>
Information Platform and Solutions<br>
Westborough, MA 01581<br>
direct: voice and FAX 508-599-7148<br>
assistant: Pam Riordan <br>
priordan@us.ibm.com
<br>
508-599-7046<br>
<br>
</font>