- dfdl-wg - lists.ogf.org

Confirmed: OGF DFDL Working Group Call (4 Sep 15:00 GDT)
by Steve Hanson 04 Sep '18

04 Sep '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

Cancelled: OGF DFDL Working Group Call
by Steve Hanson 21 Aug '18

21 Aug '18

1 0

Latest OGF DFDL WG Call Minutes
by Steve Hanson 16 Aug '18

16 Aug '18

Please find minutes from the latest call at https://redmine.ogf.org/projects/dfdl-wg/news Regards Steve Hanson IBM Hybrid Integration Architect, IBM DFDL, Co-Chair, OGF DFDL Working Group smh(a)uk.ibm.com tel:+44-1962-815848 mob:+44-7717-378890

1 0

Updated Errata doc - Experience 4 doc - with addition to Erratum 5.32
by Mike Beckerle 15 Aug '18

15 Aug '18

Per recent email threads - another place was found that needed the same change as detailed in Erratum 5.32, so that was just augmented to also specify the same change. (The issue of nil representation being empty string requires %ES; or %WSP*; alone. (The latter having been omitted in now two identified places.) 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 1

Agenda for next OGF DFDL WG Call
by Steve Hanson 06 Aug '18

06 Aug '18

Please find agenda for call on Redmine at https://redmine.ogf.org/dmsf_files/13578?download= Regards Steve Hanson IBM Hybrid Integration Architect, IBM DFDL Co-Chair, OGF DFDL Working Group smh(a)uk.ibm.com tel:+44-1962-815848 mob:+44-7717-378890

1 0

OGF DFDL Working Group Call
by Steve Hanson 06 Aug '18

06 Aug '18

1 0

Clarification discussion points for next call(s) - DFDL Spec issues around nil, empty, normal, absent, defaulting, and separator suppression.
by Mike Beckerle 02 Aug '18

02 Aug '18

I'm trying to tighten up my understanding of section 9 materials around establishing representation, known to/not-to exist, and defaulting, particularly as they interact with separators and separator suppresssion for "absent" representations. Section 9.2.5 This sentence The nil representation can be a zero-length representation if dfdl:nilValue is "%ES;", and there is no framing or framing is suppressed by dfdl:nilValueDelimiterPolicy. Should say ".... if dfdl:nilValue is a list containing either %ES; alone, or %WSP*; alone, and ...." This matches existing erratum 5.32. It's just another place that needs the same update. Sections 9.2.1 to 9.2.4 do not say what happens if when trying to establish the representation, an assertion failure occurs. In particular, can an assertion failure cause establishing of nil, empty, or normal represntation to fail, resulting in absent representation? For example, if an assert requires the length of the value to be greater than 1 character, then a zero-length string cannot be the normal representation. But do we parse to nil representation and run assertions - and if fail, parse for empty representation, then re-run assertions, and if fail parse for normal representation, then re-run assertions, and if fail and the rep was "trivially ZL", then it is absent? Section 9.2.3 doesn't say what happens if a type conversion error happens when trying to establish Normal representation. E.g., if a non-defaultable text integer is parsed from a zero-length string. T A section 9.2.5 should be added describing "No representation" - Computed elements (dfdl:inputValueCalc) have no representation at all. Not zero length, not anything. They have no implications for parsing of, or unparsing of, delimiters of any kind. Section 9.3 Section 9.3.1.1 says establishing known-to-exist, no processing error can occur. For example, an element can have zero-length representation if it is nillable and nilValue=%ES; and there are no delimiters nor framing. But an assert can fail for this by specifically excluding dfdl:valueLength(.) eq 0. Or an element of type string can have zero length, but an assert can insist the string contain 1 or more characters. Section 9.3.1.3 says known not to exist if the occurence is Missing, which means absent representation is one way. So can an assert that causes nil, empty, and normal representation to fail (assuming asserts are evaluated and contribute to that decision about representation) can cause the occurrence to be absent; hence, missing. It also says a processing error when parsing the component means it is known not to exist. Section 9.3.2 Establishing Representation Section 9.3.2.1 Simple Element (1) already has an erratum allowing WSP* alone as well as ES. Does not say whether (2) empty representation - qualified by "empty representation must be able to be of zero-length". (3) normal representation - does not say if asserts can fail and prevent this zero-length from being acceptable. (actually this point about assertions applies to all of 1, 2, and 3. Section 9.3.2.2 Complex Element If a complex type element is lengthKind 'delimited' do we still have to recurse the type before deciding if it is trivially zero length, or can we look at the data stream without recursing in? Section 9.3.2 5th bullet says that we can look for if a delimiter is immediately encountered, and does not say this is for simple types only. A complex type element can have empty representation if the content region is empty and the delimiters with EVDP specify what is found in the data stream. Absent representation for a complex element can only occur if the representation is zero length after recursing through the type tree. This implies that if EVDP indicates delimiters for empty value, then ZL means absent. Section 9.3.3 StopValue seems like it has a point of uncertainty for every occurrance. The fact that a stop value must exist doesn't mean there are no points of uncertainty. It is uncertain if the logical value will be the stop value or not. But another way of thinking about it is that the stopvalue parser does not need to establish points for backtracking. All elements MUST succeed until it parses a successful stop value, and if any failure occurs we backtrack the entire array, not just an element. Use of stopValue with type xs:string creates lots of ambiguities. E.g., ZL can be a valid normal representation, but the stop value may be "stop", i.e., non-ZL. In that case, since all elements are optional according to minOccurs 0, then when a ZL is parsed is the optional element suppressed? Or not - meaning you get an array full of empty string "normal" values? Section 9.4.2 Says a complex type must have descended into the type and returned with no processing error, but does not say whether processing errors signaled by asserts on simple type elements also disable empty representation from being established. Section 9.4.2.2 Says if EVDP is not none, can an assert insist on something that subverts establishment of empty representation, such as that the length is > 0? Or the assert can test something orthogonal - entirely unrelated like some variable is set to a certain value? E.g., <defineVariable name="disallowEmptyValues" type="xs:boolean".../> Then an assert on the element says { if ($disallowEmptyValues) then false else true }. For optional occurrence, if EVDP is not none, then empty representation is established by the presence of some positive syntax - the representation is not ZL. However, this says a empty string or empty hexbinary becomes the value, not the default value of the element. Is that correct? I would think having positive syntax that matches the empty representation would satisfy known-to-exist, and then that would trigger assigning the default value. However, I suppose the rationale is that such an empty value for an optional element means there will be no defaulting, hence, the empty representation corresponds to empty string or empty hexBinary as "normal" representation. The suggestion to use an assert that checks a non-zero minLength facet only makes sense if the processing error will cause the end of the array (occursCountKind parsed or implicit). If the OCK is such that there is no point of uncertainty, then this processing error would cause the whole array-element to fail. That is, the assert suggested here really does too much to be used only to filter empty strings/hexBinary from going into the infoset. Or does a ZL failure for a delimited simpleType value, where the text is ZL, but the type conversion fails, or an assert fails, does that create Absent representation resulting in no empty string going into the infoset? I suspect this issue is tied up with separator suppression policy and when a ZL thing is suppressed, the separator absorbed, and nothing goes into the infoset. 9.4.2.3 - suggests that processors must keep track of the "all empty flag" for every infoset node and recursively all child nodes. This section should say that a complex type has empty representation if it is known to exist, and the position in the data doesn't change after a recursive traversal. But this last paragraph of the section contradicts what is said in the 2nd sentence of the section (maybe). The point the example is making - the principle it is illustrating, does not seem to be explicilty stated. 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 3

Minor spec correction - 9.3.1.1 missing numbering of 3 items.
by Mike Beckerle 02 Aug '18

02 Aug '18

In section 9.3.1.1, after the word "determination:" the next 3 lines should be numbered list items. This may have been reported before. 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>

1 1

Incorrect property name in section 12.3.6
by Steve Hanson 02 Aug '18

02 Aug '18

12.3.6 contains the following bullet: �h ��bytes�� if parent is a choice with dfdl:choiceKind ��explicit��; This should be: �h ��bytes�� if parent is a choice with dfdl:choiceLengthKind ��explicit��; 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 2

clarification needed - ambiguity about empty string and optional element
by Mike Beckerle 02 Aug '18

02 Aug '18

Consider this data of 4 characters: foo; Consider this schema where the default format is the basic general set of text-oriented defaults. <xs:element name="ex_infix" dfdl:lengthKind="implicit"> <xs:complexType> <xs:sequence dfdl:separator=";" dfdl:separatorSuppressionPolicy="anyEmpty" dfdl:separatorPosition="infix"> <xs:element name="x" type="xs:string" dfdl:lengthKind="delimited"/> <xs:element name="y" type="xs:string" minOccurs="0" dfdl:lengthKind="delimited" dfdl:occursCountKind="implicit"/> </xs:sequence> </xs:complexType> </xs:element> This is in a current Daffodil unit test, and produces this infoset: <ex_infix><x>foo</x><y/></ex_infix> That is, an empty string element is created for element 'y'. I'd like to know what IBM DFDL produces as the infoset for this example. I believe the DFDL spec is actually self-contradictory and so ambiguous here about what is the right behavior. - DFDL Spec 14.2.1 description of anyEmpty: "...any occurrences that have zero length representation MAY be omitted from the data, along with their associated separator." - Note that it says "may", not "must be". So anyEmpty is "lax" in insisting that the zero-length elements aren't present. - This doesn't clarify anything for us. But it admits the possibility that the ";" separator appears even if the 'y' element occurrence is determined to not exist. - DFDL Spec 9.3.1.1 says an element is known to exist if it has the nil, empty, or normal representation - In the example, element 'y' is zero-length which is either empty or normal representation since a string can have "" (empty string) as a value. - Since the 'y' element decl does not specify a XSD default value, the concept of 'empty' and defaulting doesn't apply here, so a zero-length string is a normal representation, and according to this section, it is known-to-exist. - This contradicts 9.4.2.2 below. - DFDL Spec 9.3.1.3 says "Note: based on the above, when processing a sequence for which a separator is defined, the presence of a match in the data for the separator is not sufficient to cause the parser to determine that an associated component is known-to-exist." It then refers you to 14.2.1 - I don't think this changes anything. Again it just admits that the separator ";" can appear even without the following element. I.e., I think it just allows for lax processing of excess separators. - DFDL Spec 9.4.2 Element Defaults When Parsing - Subsection 9.4.2.2 Simple element (xs:string or xs:hexBinary) (Emphasis below is mine) - Here's the excerpted text: - - "Required occurrence:* If the element has a default value* then an item is added to the infoset using the default value, otherwise an item is added to the Infoset using empty string (type xs:string) or empty hexBinary (type xs:hexBinary) as the value. Optional occurrence: If dfdl:emptyValueDelimiterPolicy is not 'none'[12] <http://daffodil.apache.org/docs/dfdl/#_ftn12> then an item is added to the Infoset using empty string (type xs:string) or empty hexBinary (type xs:hexBinary) as the value, *otherwise nothing is added to the Infoset. * Note: *To prevent unwanted empty strings *or empty hexBinary values from being added to the Infoset, use XSD minLength > '0' and a dfdl:assert that uses the dfdl:checkConstraints() function, to raise a processing error." - Note that the language states "if the element has a default value" - which denotes that the section is dealing with both defaultable AND non-defaultable elements, and is not exclusively discussing defaultable elements as the title of 9.4.2 would imply. - The second statement is about optional occurrences, and it does not qualify what it says on defaultable element or not. Hence, I read the "nothing is added to the infoset" as applies whether or not the element is defaultable. So a zero length (ZL) string is never going to create an empty-string value for an optional element. - However, this contradicts the note about preventing unwanted empty strings. That note is only sensible if optional elements of zero-length will get added to the infoset and extra steps are required to force a facet check to prevent them. Unless I'm missing another place in the DFDL spec that clarifies this, I think we need to revise this area to make things clearer. But first we have to pick which is the intended semantics. In the example above, which infoset is the one we want: <ex_infix><x>foo</x><y/></ex_infix> (empty string as normal representation takes priority over optionality) or <ex_infix><x>foo</x></ex_infix> (optionality takes priority over empty string as normal representation) Either way I think this change is needed: - Section 9.4.2 - change section title to "Element Defaults and Optionality When Parsing" But a bunch of other clarifications are also needed. Today Daffodil 2.1.0 implements the first behavior. <ex_infix><x>foo</x><y/></ex_infix> with the empty 'y' element. What does IBM DFDL do? 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 3