October 2018 - dfdl-wg - lists.ogf.org

clarification needed: unparsing and hidden group choices and choices with dfdl:choiceDispatchKey
by Mike Beckerle 13 Dec '19

13 Dec '19

So interesting issue. Comes up as part of our experience implementing the advanced expression language features: hidden groups, and computed elements. We have hidden groups in DFDL. If a xs:choice is inside a hidden group, then by definition, when unparsing, elements corresponding to some branch of the choice are not in the Infoset. DFDL spec clearly states that dfdl:outputValueCalc is not allowed on the head of a choice branch. But elements inside hidden groups must have dfdl:outputValueCalc, or a default value, otherwise there's no way for them to be filled in as part of the augmented infoset. So the only way a choice can be inside a hidden group is if the head of the choice branches have default values. This is not sufficient. I do not think it was our intention to make hidden groups incapable of holding things complex enough to contain a choice. Rather, the point is to be able to hide things that have excess complexity needed only for parsing/unparsing, so that they need not appear in the final Infoset. So if a choice is allowed inside a hidden group, then a mechanism is needed by which when unparsing a choice branch is selected based on values of other parts of the Infoset, and then the elements of that branch are computed and added to the augmented infoset. Note that without hidden groups, this problem never arises, as the Infoset always has to take a position on choice branches by having an unambiguous element in it. There are 3 cases: 1. unparsing an xs:choice where for parsing, each branch has a discriminator, or is resolved by the simple "first successful parse" rule. 2. unparsing an xs:choice with dfdl:choiceDispatchKey 3. unparsing xs:choice with dfdl:initiatedContent='yes' For all cases, I suggest we must remove the restriction on dfdl:outputValueCalc being disallowed on choice branch head. For (1). First branch where the branch can be constructed successfully is added to the augmented infoset. This is a case where an unparse error is non-fatal, and causes a form of unparser backtracking through alternatives. Branches would be attempted in schema order. For (2) I suggest dfdl:unparseChoiceDispatchKey, evaluated at unparse time only. Produces a choice branch key. That choice branch is then constructed, and default values or dfdl:outputValueCalcs are used to fill in values. (BTW: this is the driving use case we have in Daffodil for this issue.) For (3).... I have no specific solution. I think it may not actually be a separate case and has to be treated as (1) or (2). Comments/Discussion?

2 1

Consolidated Notes including both DFDL WG Call 2018-08-07 along with other recent clarification email threads
by Mike Beckerle 03 Jul '19

03 Jul '19

This message includes two parts. Part 1 is the things we discussed on the DFDL WG Call of 2018-08-07. Part 2 is the other recent emails where the conclusion from the email thread is repeated here for finalization/refinement, and for consolidation so all these changes can be considered together. ================================ Part 1 - Discussed on the call. Re: [DFDL-WG] Clarification discussion points for next call(s) - DFDL Spec issues around nil, empty, normal, absent, defaulting, and separator suppression. Dated August 2nd Conclusions: Section 9.3.1.1 Delete phrase "...this of course implies that....". Note that there is already a correction to create numbered bullets of 3 sentences. The sentence containing this phrase will be bullet #3 of that list. Section 9.4 Item 2 under "For elements and element refs:" Change to: "dfdl:element following property scoping rules, which includes establishing representation as described in Section 9.3.2 and conversion to element type for simple types." Section 9.3.2 The phrase "The first step is to see if the content is trivaill of length zero." Change to: "The first step is to see if the SimpleContent or ComplexContnet region is of length zero as a first approximation." The bullet "delimited => length is zero (delimiter is immediately encountered)" Insert "in scope" after the open parenthesis. Section 9.4.2.3. We agreed that the paragraphs beginning with "For both required and optional..." need to be better tied to the material above. Wording TBD - pending Steve Hanson doing some tests on IBM DFDL. ============================ Part 2 - Below are conclusions from the prior email threads. This is for email review in lieu of discussion on this week's call. Re: [DFDL-WG] clarification: on suppressed ZL string/hexBinary - do we keep variable assignments?Of Aug 6 (last date in the thread) These corrections apply: Sections 9.4.2.2 and 9.4.2.3 The phrase "Optional occurrence: If dfdl:emptyValueDelimiterPolicy is not 'none'[12] <http://daffodil.apache.org/docs/dfdl/#_ftn12>," Change to "Optional occurrence: if dfdl:emptyValueDelimiterPolicy is applicable and is not 'none',...." (retaining the footnote) Section 9.4.2 Before the final phrase "There are three main cases to consider:" Insert this sentence: "The sections below indicate when an item is added to the infoset, and whether it has a default or other value. If there is no processing error then regardless of whether an item is added to the infoset or not, any side-effects due to dfdl:discriminator statements evaluating to true, or dfdl:setVariable statements, are retained." Section 12.2 For property emptyValueDelimiterPolicy, before the phrase "It is a schema definition error if...", insert this sentence: "The value of dfdl:emptyValueDelimiterPolicy should only be checked if there is a dfdl:initiator or dfdl:terminator in scope. If so, and dfdl:emptyValueDelimiterPolicy is not set, it is a schema definition error. If dfdl:initiator is not "" and dfdl:terminator is "" and dfdl:emptyValueDelimiterPolicy is 'terminator' it is a schema definition error. If dfdl:terminator is not "" and dfdl:initiator is " and dfdl:emptyValueDelimiterPolicy is 'initiator' it is a schema definition error." Section 13.16 For property nilValueDelimiterPolicy, before the phrase "It is a schema definition error if...", insert this sentence: "The value of dfdl:nilValueDelimiterPolicy should only be checked if there is a dfdl:initiator or dfdl:terminator in scope. If so, and dfdl:nilValueDelimiterPolicy is not set, it is a schema definition error. If dfdl:initiator is not "" and dfdl:terminator is "" and dfdl:nilValueDelimiterPolicy is 'terminator' it is a schema definition error. If dfdl:terminator is not "" and dfdl:initiator is " and dfdl:nilValueDelimiterPolicy is 'initiator' it is a schema definition error ." Section 9.2.2 The phrase "the occurrence's content in the data..." replace with "the occurrence's SimpleContent or ComplexContent region in the data..." The sentence: "The *empty representation* is special in DFDL, because when parsing it is this condition that can trigger the creation of a default value for an element occurrence." replace with: "The empty representation is special in DFDL because when parsing it it is used to determine when default values are created in the Infoset, and when optional recurring elements are omitted from the Infoset. The empty representation can require initiators or terminators be present so as to enable data formats to explicitly distinguish empty-string/hexBinary values (which might cause default values to be used) from emptiness meaning the absence of any representation." (This is to clarify an error of omission - prior language suggested that EVDP is only relevant when the element has a default value, because only that need was mentioned.) Re: [DFDL-WG] Clarification needed: separator for empty sequence Of Aug 2 Section 14.2 For property dfdl:separator. The sentence: "Separators occur in the data either before, between or after all occurrences of the elements or groups that are the children of the sequence." replaced with "Separators occur in the data either before, between or after all occurrences of *represented* elements (that is, elements without the dfdl:inputValueCalc property) or model groups that are the children of the sequence. Elements with dfdl:inputValueCalc have no representation in the data stream, and so never have separators. Children of a sequence that are model groups are always separated, even if they are empty (meaning have no children of their own - which is allowed for sequence groups), or both the model group child and its contained children occupy zero-length in the data stream." (note: Some of the above is redundant with stipulations in the dfdl:inputValueCalc property description, but I believe it is wise to have this little redundancy.) ====================== These email threads are mentioned here to indicate that they are resolved by one or another of the above corrections: Re: [DFDL-WG] clarification needed - ambiguity about empty string and optional element Of Aug 2 Re: [DFDL-WG] Spec correction ? - Section 9.3.2.1 - second list missing "empty" representationOf Aug 2 ----------- Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | www.tresys.com Please note: Contributions to the DFDL Workgroup's email discussions are subject to the OGF Intellectual Property Policy <http://www.ogf.org/About/abt_policies.php>

2 7

Re: [DFDL-WG] Action Item: Versioning mechanism for DFDL v2.0 features/changes
by Mike Beckerle 28 Apr '19

28 Apr '19

So if a schema doesn't use dfdl:format at all, then it doesn't hurt to add <dfdl:format DFDLVersion="2"/> to it at top level in order to express version when DFDL v2.0 features are added to it. I think the alternative would be a separate annotation element <dfdl:version value="2"/> that is explicitly for this purpose, is allowed only at top level, etc. That would eliminate the complexity of getting a DFDLVersion by way of a dfdl:ref that includes a named format. It could be required to just be at lexical top level of every schema document that uses v2.0 features. The reason not to change namespaces, even though that is what we thought we should do originally, is based on various guidance such as http://www.xml.com/pub/a/2004/07/21/design.html These comments mostly apply to versioning of individual DFDL schemas, not of the schema-defining language itself. The quintessential example of a language version changing is XMLSchema itself which now has version 1.1. This still uses the same namespace as XMLSchema 1.0. Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | www.tresys.com Please note: Contributions to the DFDL Workgroup's email discussions are subject to the OGF Intellectual Property Policy <http://www.ogf.org/About/abt_policies.php> On Tue, Jan 23, 2018 at 11:36 AM, Steve Hanson <smh(a)uk.ibm.com> wrote: > Mike, > > Your scheme as proposed has a couple of problems. > a) It is possible to create a schema that does not use dfdl:format at all. > Unlikely but possible. With such a schema there is no way to indicate > version. > b) What are the version implications for annotations that have nothing to > do with dfdl:format? Asserts, discriminators, variables. > > Most of the language you use refers to versions of *schemas*. That's not > the same as version of a dfdl:format. Any reason you didn't just change the > DFDL namespace URL to be *http://www.ogf.org/dfdl/dfdl-2.0/* > <http://www.ogf.org/dfdl/dfdl-2.0/>, which must be declared before any > DFDL feature can be used? I think that was always the intent of the DFDL > namespace. > > The key piece of work is validating any proposal against the scoping rules > in section 8 of the spec. > > Regards > > Steve Hanson > > IBM Hybrid Integration, Hursley, UK > Architect, *IBM DFDL* > <http://www.ibm.com/developerworks/library/se-dfdl/index.html> > Co-Chair, *OGF DFDL Working Group* <http://www.ogf.org/dfdl/> > *smh(a)uk.ibm.com* <smh(a)uk.ibm.com> > tel:+44-1962-815848 <+44%201962%20815848> > mob:+44-7717-378890 <+44%207717%20378890> > Note: I work Tuesday to Friday > > > > From: Mike Beckerle <mbeckerle.dfdl(a)gmail.com> > To: dfdl-wg(a)ogf.org > Date: 23/01/2018 16:03 > Subject: [DFDL-WG] Action Item: Versioning mechanism for DFDL v2.0 > features/changes > Sent by: "dfdl-wg" <dfdl-wg-bounces(a)ogf.org> > ------------------------------ > > > > > There are some features now under discussion which will most likely not be > part of the DFDL v1.0 standard, but a subsequent version 2.0 of the > standard. > > Implementations may have these features prior to the existence of that > draft version of the DFDL standard; hence, a mechanism for indicating the > support, and requirements that implies, on DFDL schemas is needed in order > for these v2.0 features to be introduced. > > The purpose of the versioning mechanism is to provide access to DFDL v2.0 > features, while maintaining also backward compatibility with DFDL v1.0 > schemas. > > For example, new DFDL format properties may be added to the DFDL v2.0 > version; however, those properties are not required to be specified unless > the version of the schema is specifically set to indicate it is using > version 2.0 features. Also, deprecated features should only generate > deprecation warnings if the user is requesting version 2.0 of DFDL, and > should be silent otherwise. > > Proposal: > > New attribute on the dfdl:format annotation: DFDLVersion with valid values > "1", "2". All values are reserved for future use. > > The DFDLVersion, if unspecified, defaults to "1" which means the > implementation is of the DFDL v1.0 specification. > > If the DFDLVersion is "2", then new requirements for version 2.0 of DFDL > may be enforced on the schema, and schema definition errors will result if > version 2.0 requirements are not met. DFDL Version 1.0 features that are > deprecated will generate warnings. > > Example: > > <dfdl:format DFDLVersion="2" .../> > > Example: > > <dfdl:defineFormat name="myV2Format"> > <dfdl:format DFDLVersion="2" .../> > </dfdl:defineFormat> > > The DFDLVersion is not a format property and is not scoped. It can be > added to a named format definition which is then referenced in the usual > manner for named format definitions. > > Backward Compatibility Requirement > > DFDL Implementations that provide version 2.0 functionality must also > provide DFDL v1.0 compatibility. That is, version 2.0 subsumes and extends > version 1.0. > > Mixed Version Schemas > > If a schema consists of multiple schema documents, and their respective > dfdl:format annotations do not all contain the same value for the > DFDLVersion attribute, then the schema is said to be "mixed version". This > is allowed. > > A named dfdl:format carrying DFDLVersion "2" may not be referenced from a > DFDL Schema document having DFDLVersion "1". > > The opposite is allowed: A named dfdl:format carrying DFDLVersion="1" or > lacking the DFDLVersion attribute may be referenced from a DFDL Schema > having DFDLVersion="2". > > There are really 3 ways that DFDL version 2.0 can differ from version 1.0, > and these are that new features are added, old features are deprecated, or > old features are removed. This latter is quite undesirable, but will be > considered a possibility for purpose of discussion this versioning system. > > These will commonly be in combination such as if an old feature is > deprecated with the replacement feature being added. > > These will now be discussed separately, with the emphasis on how mixed > version schemas must work. > > New Features Added > > Each new required DFDL property introduced for version 2.0 will be defined > along with what is called its "version 1.0 default value". When a mixed > version schema exists, the DFDL v1.0 parts of it behave as if any required > DFDLVersion 2 properties have their version 1.0 default value defined, at > top level of the schema (as if defined with that default value in each > DFDLVersion 1 schema document's dfdl:format annotation). > > Features Removed > > Incompatibilities are to be avoided wherever possible, and may not be > needed at all. However, there is still the possibility that some feature > will want to be entirely removed and replaced by something better, and in > that case the versioning scheme needs to be able to support this. > > In that situation, the schema definition error for version 2 is only > generated when a schema has DFDLVersion 2 specified (in dfdl:format > explicitly, or by reference to a named format carrying or referencing > DFDLVersion 2). Mixed schemas that contain schema documents entirely using > version 1 of DFDL do not generate this schema definition error. > > Features deprecated > > Deprecation warnings are generated only when a DFDLVersion="2" attribute > is present or is incorporated by reference (to a named format). A version 1 > schema that is incorporated with a version 2 DFDL schema but is not > modified in any way, does not generate deprecation warnings about version > 1.0 features that have been deprecated in version 2.0. > > (Most likely deprecations would be revising property names or value enums > for clarity.) > > Implementations may provide mechanisms for suppressing warnings. These are > implementation dependent. > > Version 1.0 Existing Deprecations and Compatibility > > During the process of standardization for DFDL v1.0 a number of properties > names were changed. DFDL version 1.0 implementations accept both the old > and new property names. > (Example: dfdl:separatorSuppressionPolicy, which replaced an older > property name.) DFDL schemas that specify DFDLVersion="2" will not accept > the older property names, and it is a schema definition error if the old > (pre DFDL v1.0) property names are used. > > Properly constructed mixed version schemas can still depend on the older > property names in the version 1.0 parts of the schema. > > ------------------------------ > > > Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | > *www.tresys.com* > <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.tresys.com&d=DwMFaQ…> > Please note: Contributions to the DFDL Workgroup's email discussions are > subject to the *OGF Intellectual Property Policy* > <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ogf.org_About_abt-5…> > -- > dfdl-wg mailing list > dfdl-wg(a)ogf.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__www. > ogf.org_mailman_listinfo_dfdl-2Dwg&d=DwICAg&c=jf_ > iaSHvJObTbx-siA1ZOg&r=AJa9ThEymJXYnOqu84mJuw&m=lDIa8xvu2n-e8 > PXWCJmajfYaXESMqvvOWpg1HMWeuGQ&s=hdO_VQ_p-1f7JfZPcSTPR1S_Y1a > nSBXJWarqPdJZdPc&e= > > 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 > >

2 6

Action 307 - Demonstrate implementation interoperability
by Steve Hanson 03 Apr '19

03 Apr '19

Action 307 was raised recently and first task is for implementations to identify which core spec behaviour is not implemented. IBM DFDL The following is the list of DFDL 1.0 spec core features that IBM DFDL does not yet implement. - dfdl:encodingErrorPolicy "replace" - dfdl:binaryBooleanTrueRep with value empty string - dfdl:assert on global element and simple type - dfdl:discriminator on global element and simple type - Multiple xs:appinfo elements within each xs:annotation element - When parsing, the distinction between an element being 'missing', having an 'empty representation' and having an 'absent representation', is not in accordance with the specification. - When encoding is 'UTF-8' or 'UTF-16', byte order marks are not processed The above lists are derived from information at https://www.ibm.com/support/knowledgecenter/en/SSMKHH_10.0.0/com.ibm.etools… and are those that apply to core spec features. Regards Steve Hanson IBM Hybrid Integration, Hursley, UK Architect, IBM DFDL Co-Chair, OGF DFDL Working Group smh(a)uk.ibm.com tel:+44-1962-815848 mob:+44-7717-378890 Note: I work Tuesday to Friday 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

2 6

clarification on behavior of DFDL encodingErrorPolicy='error' and pre-decoding by implementations
by Mike Beckerle 06 Dec '18

06 Dec '18

The DFDL spec isn't clear on when encodingErrorPolicy 'error' is allowed to cause an error, and when one must be suppressed, if the implementation pre-decodes data into characters. Example: Suppose you have what turns out to be 8 characters of text, followed by some binary data. Suppose a DFDL implementation happens to always try to fill a buffer of 64 decoded characters, just for efficiency reasons. Depending on what is in the binary data, this may parse the 8 characters of text without error, but subsequently hit a decode error, because it has strayed into binary data past the text. There is no actual decode error in the data stream, because parsing should determine there are only 8 characters of text, and then switch to parsing the binary data using binary means. The DFDL spec doesn't say this isn't allowed to cause a decode error. Perhaps it is implied somewhere? But I didn't find it. The DFDL spec does point out that for asserts/discriminators with testKind pattern, that pattern matching may cause decode errors. But again, suppose the regex matching library an implementation uses happens to pre-fetch and pre-decode a bunch of characters, but the regex matching library then finds a match that is quite short, and stops well before the characters that were pre-decoded that caused a decode error. It would seem to me that this sort of pre-decoding should not cause decode errors. but the DFDL spec doesn't state that explicitly. comments? Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | www.tresys.com Please note: Contributions to the DFDL Workgroup's email discussions are subject to the OGF Intellectual Property Policy <http://www.ogf.org/About/abt_policies.php>

2 2

Action 292 - Write up of hexBinary with lengthUnits 'bits'
by Mike Beckerle 20 Nov '18

20 Nov '18

The proposed change is to allow lengthUnits 'bits' for hexBinary data. This turned out to be more complex to describe than I originally suspected because of the need to deal with XSD minLength and maxLength facets, which are always measured in bytes. Those in conjunction with dfdl:lengthKind='explicit' and dfdl:lengthUnits='bits' create some minor complexities. The below changes match the Daffodil implementation of this proposed feature. These sentences in the description of dfdl:lengthUnits in Section 12.3 must change. - '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 binary representation. - 'bytes' must be used for type xs:hexBinary. The text should read - 'bits' may only be used for xs:hexBinary and for xs:boolean, xs:byte, xs:short, xs:int, xs:long, xs:unsignedByte, xs:unsignedShort, xs:unsignedInt, and xs:unsignedLong simple types with binary representation. Later in the section, the paragraph: When unparsing a simple element with binary representation, then for hexBinary the length is the number of bytes in the infoset value padded to the XSD minLength facet value using dfdl:fillByte, and for the other types the length is the minimum number of bytes to represent the value and any sign. Must change to: When unparsing a simple element with binary representation, then for types other than hexBinary the length is the minimum number of bytes to represent the value and any sign. For type hexBinary when the dfdl:lengthUnits is 'bytes' then the length is the number of bytes in the infoset value padded to the XSD minLength facet value using dfdl:fillByte. For type hexBinary when the dfdl:lengthUnits is 'bits': - First the data is padded to XSD minLength bytes as if the dfdl:lengthUnits was 'bytes'. - When dfdl:lengthKind is other than 'explicit', the length is the number of bytes times 8. - When the dfdl:lengthKind is 'explicit' then the value is further padded or truncated to fit the target length, in bits. - if the data does not have sufficient bytes to supply the target length in bits it is a processing error. - if the data is longer than the minimum number of bytes needed to supply the target length in bits, it is a processing error. - If the explicit length in bits is not a multiple of 8, then the final byte is only partially unparsed according to the current dfdl:byteOrder. Section 12.3.7.2.7 Length of Binary Opaque Elements, the first sentence must be modified from: "The dfdl:lengthUnits property must be 'bytes'. It is a schema definition error otherwise." to "The dfdl:lengthUnits property must be 'bytes' or 'bits'. It is a schema definition error otherwise. Note that even when the dfdl:lengthUnits property is 'bits', the values of the XSD minLength and XSD maxLength facets are still always interpreted as constraining the length in units of bytes. That's the end of the actual proposed language. Note about alternatives: I considered the alternative to make it a schema definition error when dfdl:lengthUnits is 'bits' type is 'xs:hexBinary', and the XSD:minLength or XSD:maxLength facets are defined. I decided to go with the description above to support the use case where a data item is, in hex, some number of bytes long for a valid XML infoset, but the representation is explicitly a partial byte smaller. E.g., in a hexBinary with 8 bytes, but fewer than 64 bits in the representation. Ex: 63 bits as the explicit target length, so 1 bit will be unused from the xs:hexBinary logical value, but the above rules insure no more than 7 bits go unused from the final byte of the hexBinary logical value. This is trying to be consistent with the notion that we do not truncate data to fit into the available length except for xs:string when properties explicitly allow it. It is also trying to be consistent with our treatment of binary integers where a xs:long value may be output into an element having room for any number of bits, and any extra bits in the logical value are ignored. Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | www.tresys.com Please note: Contributions to the DFDL Workgroup's email discussions are subject to the OGF Intellectual Property Policy <http://www.ogf.org/About/abt_policies.php>

2 2

Rescheduled: OGF DFDL Working Group Call (1 Nov 15:00 GMT)
by Steve Hanson 25 Oct '18

25 Oct '18

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

OGF DFDL Working Group Call
by Steve Hanson 25 Oct '18

25 Oct '18

1 0

OGF DFDL Working Group Call
by Steve Hanson 25 Oct '18

25 Oct '18

1 0

OGF DFDL Working Group Call
by Steve Hanson 25 Oct '18

25 Oct '18

1 0