- dfdl-wg - lists.ogf.org

OGF DFDL WG Call Agenda 2013-06-04
by Steve Hanson 03 Jun '13

03 Jun '13

Please find agenda for call on Redmine at http://redmine.ogf.org/dmsf_files/13082?download= Regards Steve Hanson Architect, IBM Data Format Description Language (DFDL) Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848

1 0

lengthUnits 'bits' and binaryNumberRep
by Steve Hanson 03 Jun '13

03 Jun '13

For discussion on next WG call: The description of the dfdl:lengthUnits property for enum 'bits' says (after errata 2.90): 'bits' may only be used for xs:boolean, xs:byte, xs:short, xs:int, xs:long, xs:unsignedByte, xs:unsignedShort, xs:unsignedInt, and xs:unsignedLong simple types with representation 'binary'. This is permitting binary numbers with dfdl:binaryNumberRep 'packed', 'bcd' and 'ibm4690Packed' to have dfdl:lengthUnits 'bits'. That could make sense, as one could have an odd number of nibbles packed into the minimum space possible - eg a BCD range 000-999 could occupy 12 bits. However, the words that have been added for errata 2.90 (allowing signed number types to have lengthUnits 'bits') to both the description of dfdl:lengthUnits and section 12.3.7.2 have assumed that only binaryNumberRep 'binary' is allowed. I tested IBM DFDL with 12-bit 'packed' and 'bcd' reps packed back-to-back with bit alignment and it parsed them ok, but gave an error when serializing, saying that binaryNumberRep must be 'binary'. Clearly incorrect because of the inconsistency, but what is the intent of the spec here? Regards Steve Hanson Architect, IBM Data Format Description Language (DFDL) Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848 Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

1 0

0 equals ""?
by Garriss Jr., James P. 03 Jun '13

03 Jun '13

When are these not functionally equal? <dfdl:discriminator>{ dfdl:valueLength(../Empty, "bytes") eq 0 }</dfdl:discriminator> <dfdl:discriminator>{ ../Empty eq "" }</dfdl:discriminator> TIA

2 1

escapeKind clarifications needed.
by Mike Beckerle 31 May '13

31 May '13

When escapeKind='escapeBlock' we only use the escapeEscapeCharacter if needed to escape the block end. We don't use the escapeCharacter at all. So, is it an error if escapeKind='escapeBlock' and you define a value for escapeCharacter in the same dfdl:escapeScheme? Such property cannot be inherited by scope, so since escapeBlock kind doesn't use the escapeCharacter, this can only be either an error, or silently ignored, or ignored with a warning. An error is the best choice from a language design perspective. -- Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | www.tresys.com

2 1

Fwd: [dfdl] initiatedContent w/o initiators
by Mike Beckerle 31 May '13

31 May '13

Forgot to copy the workgroup. ---------- Forwarded message ---------- From: Mike Beckerle <mbeckerle.dfdl(a)gmail.com> Date: Fri, May 31, 2013 at 1:32 AM Subject: Re: [DFDL-WG] [dfdl] initiatedContent w/o initiators To: "Garriss Jr., James P." <jgarriss(a)mitre.org> You need two nested choices. Only the inner one uses initiated content. <xsd:choice> <xsd:choice dfdl:initiatedContent="yes"> <xsd:element ref="Date"/> <xsd:element ref="From"/> <xsd:element ref="MessageId"/> <xsd:element ref="Subject"/> </xsd:choice>  <xsd:sequence dfdl:hiddenGroupRef="UnwantedHeadersGroup"/> </xsd:choice> On Thu, May 30, 2013 at 2:49 PM, Garriss Jr., James P. <jgarriss(a)mitre.org>wrote: > Spec says:**** > > ** ** > > It is a schema definition error if any children have their dfdl:initiator > property set to the empty string.**** > > ** ** > > Does that include a sequence with a hiddenGroupRef?**** > > ** ** > > For example, part of a schema for email headers is this:**** > > ** ** > > > <xsd:choice dfdl:initiatedContent="yes">**** > > > <xsd:element ref="Date"/>**** > > > <xsd:element ref="From"/>**** > > > <xsd:element ref="MessageId"/>**** > > > <xsd:element ref="Subject"/>**** > > > **** > > > <xsd:sequence dfdl:hiddenGroupRef="UnwantedHeadersGroup"/>**** > > > </xsd:choice>**** > > ** ** > > Date, From, and the other headers are all elements with initiators, but > UnwantedHeadersGroup does not have an initiator (because I don’t know it a > priori). **** > > ** ** > > Should this throw an error in a DFDL implementation? I suspect it should, > though I hope it shouldn’t.**** > > -- > dfdl-wg mailing list > dfdl-wg(a)ogf.org > https://www.ogf.org/mailman/listinfo/dfdl-wg > -- Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | www.tresys.com -- Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | www.tresys.com

2 3

Better way to model "empty"?
by Garriss Jr., James P. 31 May '13

31 May '13

A return path email header can take two forms: 1. Plain email form: Return-path: <steve(a)tresys.com> 2. Empty form: Return-path: <> I've found 2 different ways to model this: #1 - with a choice <xsd:choice> <xsd:element name="Empty" type="xsd:string" dfdl:lengthKind="explicit" dfdl:length="0"/> <xsd:element name="PlainEmail" type="PlainEmail"/> </xsd:choice> #2 - with min/maxOccurs <xsd:element name="PlainEmail" type="PlainEmail" minOccurs="0" maxOccurs="1" dfdl:occursCountKind="implicit"/> When I'm faced with selecting one of these implementations over another, how do I think? What criteria should I be using? Is there another, better way that I haven't even thought of? TIA

2 1

Re: [DFDL-WG] [dfdl] initiatedContent w/o initiators
by Garriss Jr., James P. 31 May '13

31 May '13

Thanks for the help, Mike. I understand what you want me to do, but not why. After all, the code I have works great on all the test data I've thrown at it. Please explain how this is different from the schema code I have and why it is better. TIA. From: Mike Beckerle [mailto:mbeckerle.dfdl@gmail.com] Sent: Friday, May 31, 2013 1:33 AM To: Garriss Jr., James P. Subject: Re: [DFDL-WG] [dfdl] initiatedContent w/o initiators You need two nested choices. Only the inner one uses initiated content. <xsd:choice> <xsd:choice dfdl:initiatedContent="yes"> <xsd:element ref="Date"/> <xsd:element ref="From"/> <xsd:element ref="MessageId"/> <xsd:element ref="Subject"/> </xsd:choice>  <xsd:sequence dfdl:hiddenGroupRef="UnwantedHeadersGroup"/> </xsd:choice> On Thu, May 30, 2013 at 2:49 PM, Garriss Jr., James P. <jgarriss(a)mitre.org<mailto:jgarriss@mitre.org>> wrote: Spec says: It is a schema definition error if any children have their dfdl:initiator property set to the empty string. Does that include a sequence with a hiddenGroupRef? For example, part of a schema for email headers is this: <xsd:choice dfdl:initiatedContent="yes"> <xsd:element ref="Date"/> <xsd:element ref="From"/> <xsd:element ref="MessageId"/> <xsd:element ref="Subject"/>  <xsd:sequence dfdl:hiddenGroupRef="UnwantedHeadersGroup"/> </xsd:choice> Date, From, and the other headers are all elements with initiators, but UnwantedHeadersGroup does not have an initiator (because I don't know it a priori). Should this throw an error in a DFDL implementation? I suspect it should, though I hope it shouldn't. -- dfdl-wg mailing list dfdl-wg(a)ogf.org<mailto:dfdl-wg@ogf.org> https://www.ogf.org/mailman/listinfo/dfdl-wg -- Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | www.tresys.com<http://www.tresys.com>

1 0

emptyValueDelimiterPolicy clarification
by Garriss Jr., James P. 31 May '13

31 May '13

This property specifies whether the initiator/terminator much be present if the element is empty. But the mere presence of this property does not specify that the element can be empty, right? IOW, I still have to describe that the element can be empty. That right?

2 1

[dfdl] initiatedContent w/o initiators
by Garriss Jr., James P. 30 May '13

30 May '13

Spec says: It is a schema definition error if any children have their dfdl:initiator property set to the empty string. Does that include a sequence with a hiddenGroupRef? For example, part of a schema for email headers is this: <xsd:choice dfdl:initiatedContent="yes"> <xsd:element ref="Date"/> <xsd:element ref="From"/> <xsd:element ref="MessageId"/> <xsd:element ref="Subject"/>  <xsd:sequence dfdl:hiddenGroupRef="UnwantedHeadersGroup"/> </xsd:choice> Date, From, and the other headers are all elements with initiators, but UnwantedHeadersGroup does not have an initiator (because I don't know it a priori). Should this throw an error in a DFDL implementation? I suspect it should, though I hope it shouldn't.

1 0

DFDL support for XML schema elements or attributes
by Alonza Mumford 30 May '13

30 May '13

I've looked over the DFDL 1.0 specification and I have a few questions regarding the inclusion of certain XML Schema elements or attributes. Does anyone know as to whether the following elements are supported in DFDL 1.0: - xs:extension - xs:list - xs:all - xs:any - xs:anyAttribute - xs:field - xs:key - xs:keyref - xs:selector - xs:unique Does anyone know as to whether the following elements are supported in DFDL 1.0: - xs:abstract - xs:attributeFormDefault - xs:base - xs:block - xs:blockDefault - xs:fixed - xs:mixed - xs:processContents Thanks, Alonza

2 1