<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.6000.16825" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=609563312-05052009><FONT face=Arial
color=#0000ff size=2>I can easily support this proposal.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=609563312-05052009><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=609563312-05052009><FONT face=Arial
color=#0000ff size=2>The only "downside" of restricting sequences from having
lengthKind is that you will have to introduce a named "tier" of an element in
your logical DFDL model when you need to model what is really only a physical
implementation concept, of a box surrounding data.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=609563312-05052009><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=609563312-05052009><FONT face=Arial
color=#0000ff size=2>But I've always been in favor of avoiding the slippery
slope where a DFDL schema is supposed to both describe the represenatation as
well as exhibiting a logical model that someone likes. To me the DFDL
schema is very constrained by what is required by the physical model, and
transformations outside of the DFDL schema are going to "tidy up" the model and
remove artifacts of representation. The element tier you need in this case to
express the length of a "box" surrounding content is such a representation
artifact.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=609563312-05052009><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=609563312-05052009><FONT face=Arial
color=#0000ff size=2>To me the slippery slope of allowing sequences to be almost
like unnamed elements is a slope we very much want to avoid, and as you point
out, we're already doing that by eliminating occurs behavior on them for DFDL.
</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=609563312-05052009><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=609563312-05052009><FONT face=Arial
color=#0000ff size=2>Thought: if you are going to need to transform the
DFDL-described data anyway, then introducing named tiers for these kinds of
complex physical features actually makes such transformation easier to express,
because the xpath expressions to address various parts of the DFDL-described
data are more obvious. </FONT></SPAN></DIV>
<DIV><FONT face=Arial color=#0000ff size=2></FONT> </DIV>
<DIV><SPAN class=609563312-05052009><FONT face=Arial color=#0000ff
size=2>...mike</FONT></SPAN></DIV>
<P align=left><A name=""></A><?xml:namespace prefix = st1 ns =
"urn:schemas-microsoft-com:office:smarttags" /><st1:PersonName w:st="on"><SPAN
style="mso-bookmark: ''"><B><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"></SPAN></B></SPAN></st1:PersonName><SPAN
style="mso-bookmark: ''"><B><SPAN
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Mike Beckerle |
OGF DFDL WG Co-Chair | CTO | Oco, Inc.</SPAN></B></SPAN><BR><SPAN
style="FONT-SIZE: 10pt; COLOR: gray; FONT-FAMILY: Arial">Tel:
781-810-2125 | <st1:address w:st="on"><st1:Street w:st="on">100 Fifth
Ave., 4th Floor</st1:Street>, <st1:City w:st="on">Waltham</st1:City> <st1:State
w:st="on">MA</st1:State> <st1:PostalCode
w:st="on">02451</st1:PostalCode></st1:address> |</SPAN> <A
href="mailto:mbeckerle.dfdl@gmail.com"><SPAN
style="FONT-SIZE: 10pt; COLOR: gray"><FONT
face=Arial>mbeckerle.dfdl@gmail.com</FONT></SPAN></A><SPAN
style="FONT-SIZE: 10pt; COLOR: gray; FONT-FAMILY: Arial"> </SPAN></P>
<DIV> </DIV><BR>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> dfdl-wg-bounces@ogf.org
[mailto:dfdl-wg-bounces@ogf.org] <B>On Behalf Of </B>Steve
Hanson<BR><B>Sent:</B> Wednesday, April 29, 2009 6:51 AM<BR><B>To:</B>
dfdl-wg@ogf.org<BR><B>Subject:</B> [DFDL-WG] DFDL lengthKind on complex
objects<BR></FONT><BR></DIV>
<DIV></DIV><BR><FONT face=sans-serif size=2>I have a long-standing concern about
the usability of dfdl:lengthKind, which others in IBM are encountering when
modeling real life formats such as EDI. </FONT><BR><BR><FONT face=sans-serif
size=2>My main concern is </FONT><FONT face=sans-serif color=blue
size=2>below</FONT><FONT face=sans-serif size=2>. For example, what's the
semantic of setting different values on the element and the sequence?
</FONT> <BR><BR><FONT face="Courier New" size=2><xs:element
name="container" </FONT><FONT face="Courier New" color=blue
size=2>dfdl:lengthKind="implicit"</FONT><FONT face="Courier New"
size=2>></FONT> <BR><FONT face="Courier New" size=2>
<xs:complexType></FONT> <BR><FONT face="Courier New" size=2>
<xs:sequence dfdl:separator="@" </FONT><FONT face="Courier New" color=blue
size=2>dfdl:lengthKind="implicit"</FONT><FONT face="Courier New"
size=2>></FONT> <BR><FONT face="Courier New" size=2>
<xs:element name="one" type="xs:string" dfdl:lengthKind="delimited"
/></FONT> <BR><FONT face="Courier New" size=2>
<xs:element name="two" type="xs:string" dfdl:lengthKind="delimited"
/></FONT> <BR><FONT face="Courier New" size=2>
<xs:element name="three" type="xs:string" dfdl:lengthKind="delimited"
/></FONT> <BR><FONT face="Courier New" size=2>
</xs:sequence></FONT> <BR><FONT face="Courier New" size=2>
</xs:complexType></FONT> <BR><FONT face="Courier New"
size=2></xs:element></FONT> <BR><BR><FONT face=sans-serif size=2>It gets
even more noticeable if I set a scoping dfdl:lengthKind on the complex
type.</FONT> <BR><BR><FONT face=sans-serif size=2>I propose that we limit
dfdl:lengthKind to <B>elements only</B>. It means that the length of a
xs:sequence or xs:choice is always and implicitly given by its chidren, and if
you want to provide an explicit length or a length prefix you must use a complex
element to wrap the sequence or choice. We have looked at the implications on
dfdl:choiceKind for choices, and dfdl:occursKind on arrays, and the proposal
works happily in those scenarios. </FONT><BR><BR><FONT face=sans-serif
size=2>There's an analogy here with not alowing sequences and choices to repeat,
only elements.</FONT> <BR><BR><FONT face=sans-serif size=2>It also simplifies
the grammar, in the sense that any excess fill characters in a 'box' are always
considered part of the element when parsing.</FONT> <BR><BR><FONT
face=sans-serif size=2>I'd like to discuss this on today's call.</FONT>
<BR><BR><FONT face=sans-serif size=2>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 face=sans-serif
size=2><BR></FONT><BR><FONT face=sans-serif size=2><BR></FONT>
<HR>
<FONT face=sans-serif size=2><BR><I><BR></I></FONT>
<P><FONT face=sans-serif size=2><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 face=sans-serif size=2><BR><BR></FONT><BR><BR><FONT face=sans-serif
size=2><BR></FONT></P></BODY></HTML>