<!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=656544012-05052009><FONT face=Arial
color=#0000ff size=2>This sounds good to me.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=656544012-05052009><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=656544012-05052009><FONT face=Arial
color=#0000ff size=2>I have an idea to contribute. </FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=656544012-05052009><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=656544012-05052009><FONT face=Arial
color=#0000ff size=2>If I have a choice enclosing a variable-occurs array, then
I might make the mistake of writing a discriminator for the choice, but not
realize it is resolving the variable-occurs because it is enclosed by
that.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=656544012-05052009><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=656544012-05052009><FONT face=Arial
color=#0000ff size=2>What if we added a label to discriminators to say what they
are discriminating?</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=656544012-05052009><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=656544012-05052009><FONT face=Arial
color=#0000ff size=2>In the unambiguous cases this would be redundant. In the
more subtle cases it would allow a DFDL processor to issue a superior diagnostic
message without having to be as clever.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=656544012-05052009><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=656544012-05052009><FONT face=Arial
color=#0000ff size=2>I would suggest this syntax:</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=656544012-05052009><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=656544012-05052009><FONT face=Arial
color=#0000ff size=2><dfdl:discriminator kind="choice"
..../></FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=656544012-05052009><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=656544012-05052009><FONT face=Arial
color=#0000ff size=2>or </FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=656544012-05052009><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=656544012-05052009><FONT face=Arial
color=#0000ff size=2><dfdl:discriminator
kind="occurs".../></FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=656544012-05052009><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=656544012-05052009><FONT face=Arial
color=#0000ff size=2>or</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=656544012-05052009><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=656544012-05052009><FONT face=Arial
color=#0000ff size=2><dfdl:discriminator
kind="unorderedSequence"/></FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=656544012-05052009><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=656544012-05052009><FONT face=Arial
color=#0000ff size=2>Other syntax that achieves this same separation would be
fine, e.g., we could have <dfdl:choiceDiscriminator .../> and analogous
other element names for the kinds of discriminators. </FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=656544012-05052009><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=656544012-05052009><FONT face=Arial
color=#0000ff size=2>I am not sure about the unordered sequence flavor. There's
another discussion about that going on simultaneously. To me that needs to be
resolved by way of initiators, so the discriminator is always implied; however,
if the semantics there was generalized to allow for more complex speculation
then we would need analogous discriminator constructs.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=656544012-05052009><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=656544012-05052009><FONT face=Arial
color=#0000ff size=2>...mike</FONT></SPAN></DIV>
<DIV> </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>Tim Kimber<BR><B>Sent:</B>
Wednesday, April 29, 2009 8:41 AM<BR><B>To:</B> Alan Powell;
mbeckerle@oco-inc.com; Suman Kalia<BR><B>Cc:</B>
dfdl-wg@ogf.org<BR><B>Subject:</B> [DFDL-WG] Action 033 : Assertions and
discriminators<BR></FONT><BR></DIV>
<DIV></DIV><BR><FONT face=sans-serif size=2>Hi all,</FONT> <BR><BR><FONT
face=sans-serif size=2>I have this action:</FONT> <BR>
<TABLE width="100%" border=1>
<TBODY>
<TR vAlign=top>
<TD width="7%">
<DIV align=center><FONT face=sans-serif size=2><B>033</B></FONT></DIV>
<TD width="92%"><FONT face=Arial size=2>04/03: Assert/Discriminator
semantics. AP to document. TK to check uses of discriminator besides
choice.</FONT></TR></TBODY></TABLE>
<P><BR><FONT face=sans-serif size=2>I believe the rules should be:</FONT>
<BR><BR><FONT face=sans-serif size=2>1. A point of uncertainty is any of</FONT>
<BR><FONT face=sans-serif size=2>* an element which has minOccurs !=
maxOccurs</FONT> <BR><FONT face=sans-serif size=2>* a choice</FONT> <BR><FONT
face=sans-serif size=2>* a sequence with sequenceKind="unordered"</FONT>
<BR><BR><FONT face=sans-serif size=2>2. Nested within the scope of a point of
uncertainty, there might be other points of uncertainty.</FONT> <BR><BR><FONT
face=sans-serif size=2>3. A discriminator which evaluates to true resolves the
nearest in-scope point of uncertainty. </FONT><BR><BR><FONT face=sans-serif
size=2>4. An assertion which evaluates to false causes a processing error</FONT>
<BR><BR><FONT face=sans-serif size=2>5. Any processing error ( from an assertion
failure or otherwise ) will cause the parser to backtrack to the nearest
unresolved point of uncertainty and try the next available branch, if any. If
there are no more branches available, the parser will backtrack to the next
nearest unresolved point of uncertainty.</FONT> <BR><BR><FONT face=sans-serif
size=2>6. A processing error which reaches the root tag is reported to the host
application.</FONT> <BR><BR><FONT face=sans-serif size=2>7. Assertions and
discriminators are allowed on any point of uncertainty ( not only on the
branches of a choice )</FONT> <BR><BR><BR><FONT face=sans-serif
size=2><U>Rationale:</U></FONT> <BR><BR><FONT face=sans-serif size=2>If we only
allow a discriminator on a choice branch, then it will be difficult to model
this common style of message</FONT> <BR><BR><FONT face=sans-serif size=2>Tagged
header, minOccurs="1", maxOccurs="1"</FONT> <BR><FONT face=sans-serif
size=2>Untagged body, maxOccurs="unbounded"</FONT> <BR><FONT face=sans-serif
size=2>Tagged trailer, minOccurs="1", maxOccurs="1"</FONT> <BR><BR><FONT
face=sans-serif size=2>An example with 3 occurrences of the body would
be:</FONT> <BR><BR><FONT face="Courier New"
size=2>HE,headerfield1,headerfield2,headerfield3</FONT> <BR><FONT
face="Courier New" size=2>John Smith, 100, bodyfield3</FONT> <BR><FONT
face="Courier New" size=2>John Brown, 200, bodyfield3</FONT> <BR><FONT
face="Courier New" size=2>Elton John, 30Z, bodyfield3</FONT> <BR><FONT
face="Courier New" size=2>TR,trailerfield1,trailerfield2,trailerfield3</FONT>
<BR><BR><FONT face=sans-serif size=2>And the DFDL schema would look something
like this ( excuse the almost inevitable errors, this is just for completeness
):</FONT> <BR><BR><FONT face="Courier New" size=2>...</FONT> <BR><FONT
face="Courier New" size=2><xs:element name="message"></FONT> <BR><FONT
face="Courier New" size=2> <xs:complexType
dfdl:lengthKind="implicit"></FONT> <BR><FONT face="Courier New" size=2>
<xs:sequence dfdl:separator="\r\n"></FONT> <BR><FONT
face="Courier New" size=2> <xs:element
name="header" initiator="HE,"></FONT> <BR><FONT face="Courier New"
size=2> <xs:complexType></FONT>
<BR><FONT face="Courier New" size=2>
<xs:sequence dfdl:separator=","></FONT> <BR><FONT face="Courier New"
size=2> <xs:element
name="header1" type="xs:string"></FONT> <BR><FONT face="Courier New"
size=2> <xs:element
name="header2" type="xs:string"></FONT> <BR><FONT face="Courier New"
size=2> <xs:element
name="header3" type="xs:string"></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="Courier New"
size=2> <xs:element name="body"
maxOccurs="unbounded"></FONT> <BR><FONT face="Courier New" size=2>
<xs:complexType></FONT> <BR><FONT
face="Courier New" size=2>
<xs:sequence dfdl:separator=","></FONT> <BR><FONT face="Courier New"
size=2> <xs:element
name="body1" type="xs:string"></FONT> <BR><FONT face="Courier New"
size=2> <xs:element
name="body2" type="xs:int"></FONT> <BR><FONT face="Courier New" size=2>
<xs:element name="body3"
type="xs:string"></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="Courier New"
size=2> <xs:element name="trailer"
initiator="TR,"></FONT> <BR><FONT face="Courier New" size=2>
<xs:complexType></FONT> <BR><FONT face="Courier New"
size=2> <xs:sequence
dfdl:separator=","></FONT> <BR><FONT face="Courier New" size=2>
<xs:element name="trailer1"
type="xs:string"></FONT> <BR><FONT face="Courier New" size=2>
<xs:element name="trailer2"
type="xs:string"></FONT> <BR><FONT face="Courier New" size=2>
<xs:element name="trailer3"
type="xs:string"></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><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><BR><FONT
face=sans-serif size=2>The '30Z' value for the final occurrence of element Body2
is incorrect. It is not a valid integer, and will trigger a processing
error.</FONT> <BR><BR><FONT face=sans-serif size=2>Without a discriminator, this
failure will cause the parser to backtrack to the optional field and try the
next element ( the trailer element ). The initiator will not be found, and the
reported error will be "Initiator 'TR,' not found for element 'trailer'". The
user would almost certainly prefer "Invalid value '30Z' for element 'body2'.
Value could not be converted to simple type 'xs:int'"</FONT> <BR><BR><FONT
face=sans-serif size=2>For this example, the discriminator would need to detect
unambiguously that it really was dealing with a Body element and not a Trailer
element. Due to the message style ( which is quite common ) the only way to do
this is to detect that it is *not* a Trailer. I cannot think of an elegant way
to do that using the facilities in v0.33 of the specification. I have raised
this with Alan and Steve.</FONT> <BR><BR><FONT face=sans-serif
size=2>regards,<BR><BR>Tim Kimber, Common Transformation Team,<BR>Hursley,
UK<BR>Internet: kimbert@uk.ibm.com<BR>Tel. 01962-816742 <BR>Internal
tel. 246742<BR><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>