- dfdl-wg - lists.ogf.org

Clarification needed: separator for empty sequence
by Mike Beckerle 02 Aug '18

02 Aug '18

I believe Daffodil has an incorrect behavior in the way it treats separators today, but I want to clarify things relative to the DFDL spec before fixing it. Consider this element: <xs:element name="NS_13"> <xs:complexType> <xs:sequence dfdl:separator="," dfdl:separatorPosition="infix" dfdl:separatorSuppressionPolicy="trailingEmptyStrict"> <xs:sequence> <xs:annotation> <xs:appinfo source="http://www.ogf.org/dfdl/"> <dfdl:assert>{fn:true()}</dfdl:assert> </xs:appinfo> </xs:annotation> </xs:sequence> <xs:element name="e2" type="xs:int" minOccurs="1" maxOccurs="unbounded" dfdl:textNumberPattern="#####" dfdl:occursCountKind="implicit" /> </xs:sequence> </xs:complexType> </xs:element> The outermost sequence has infix separator. It's content begins with another sequence, but this sequence is empty, having only assert statements in it. Question: does this empty sequence cause a separator to be inserted after it? E.g., Should this data parse ",1,2,3" and is that initial comma required? An argument can be made that such empty sequences can be detected by a DFDL implementation and treated as having "no representation" akin to how an element with dfdl:inputValueCalc is treated. Such elements are invisible as far as the representation is concerned. They cause no separators in sequences, no alignment regions, etc. In that case the data would not require nor accept the initial comma. But the DFDL spec is not clear on whether empty sequences are treated in this way, so I am assuming they are not treated specially, so the comma is required because all model groups are treated as required regardless of whether they have zero-length representations. Is that correct? If so then daffodil has a bug, because it does NOT put a separator in for this today. What if the empty sequence carries a dfdl:initiator="A" annotation? Such a sequence is still empty in the XSDL sense of empty sequence, but clearly has a representation that is not zero length. In that case I think the data has to be "A,1,2,3" so that there is a separator after the empty sequence's non-ZL representation. I think this is not controversial. Other variations: What if the empty sequence contains elements with dfdl:inputValueCalc only. So there is a content model, but it is all non-represented elements. Would it still be a "DFDL empty sequence" or "DFDL non-represented sequence"? What if the sequence isn't empty, but contains only "optional" elements. In that case, is the whole sequence "optional" and so the comma becomes sensitive to the dfdl:separatorSuppressionPolicy? I guess this means a model group inherits the optionality/required-ness of its contents, unless it has its own required framing. I believe the simplest thing is to require the comma here. This is, however, a backward incompatible change to Daffodil to conform, so I want to be sure this is correct. The element declaration can be rewritten so that the empty sequence comes before the separated sequence. Presumably the reason someone would insert an empty sequence like this is to get the assert statement executed at the beginning of the sequence, not afterwards. However, if the sequence has separators, then you can't just insert an initial empty sequence to carry that assert without requiring a separator. The element can be rewritten: <xs:element name="NS_13"> <xs:complexType> <xs:sequence > <xs:sequence> <xs:annotation> <xs:appinfo source="http://www.ogf.org/dfdl/"> <dfdl:assert>{fn:true()}</dfdl:assert> </xs:appinfo> </xs:annotation> </xs:sequence> <xs:sequence dfdl:separator="," dfdl:separatorPosition="infix" dfdl:separatorSuppressionPolicy="trailingEmptyStrict"> <xs:element name="e2" type="xs:int" maxOccurs="unbounded" dfdl:textNumberPattern="#####" /> </xs:sequence> </xs:sequence> </xs:complexType> </xs:element> This achieves the desired behavior where the assertion executes first, but does not cause a separator to be needed, and does so regardless of the treatment of empty sequences. Ultimately, we need a clarification that states either: 1) empty sequences are considered represented terms that are required, and hence, they imply framing such as alignment and presence of separators in separated sequences even if they have zero length. or 2) Introduce concept "DFDL non-represented sequence". These are sequences that have no framing, no delimiters, and have empty content model, or only elements with dfdl:inputValueCalc or other DFDL non-represented sequences in their content model (recursively). They have no representation, so imply no alignment, no need of separators, etc. A group ref (hidden or not) to a DFDL non-represented sequence is also a DFDL non-represented sequence. Note that these could be generalized to choice groups also. 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 3

Spec correction ? - Section 9.3.2.1 - second list missing "empty" representation
by Mike Beckerle 02 Aug '18

02 Aug '18

In section 9.3.2.1, there are two numbered lists. The first numbered list should qualify its mention of "empty representation" with "(when the emptyValueDelimiterPolicy and initiator and terminator policies are defined such that zero-length is allowed as the empty representation.)" The second numbered list should mention nil (literal), nil (logical), empty, and normal representations. It is missing discussion of non-zero-length "empty" representations (due to emptyValueDelimiterPolicy not none, and initiator and terminator defined such that the empty representation is non-zero length). 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

Clarification needed: stricter separator suppresssion policy
by Mike Beckerle 02 Aug '18

02 Aug '18

I have been trying to rationalize the definitions in the DFDL spec for separated sequences. I cannot find a way to express something very simple: A repeating element with minOccurs non-zero-length elements with separators required, and up to maxOccurs (or unbounded) non-zero-length elements with separators are allowed. This means separators can never be adjacent anywhere in the corresponding data stream (except if escaped, or hidden inside say a fixed-length string inside a complex type element). Adjacent delimiters would be a parse error. I expected this to be occursCountKind 'implicit' with separatorSuppressionPolicy 'never', but that appears to mean that maxOccurs must be bounded and there are always exactly maxOccurs separators, the latter of which (maxOccurs - minOccurs of them) can be empty strings, meaning optional elements will not be created for them. All the other 3 separator suppression policies absorb adjacent separators, except for trailingEmptyStrict doesn't absorb them at the end of the group. There doesn't seem to be a way to be strict about the format and speculatively parse only non-zero-length elements requiring each optional occurance to appear with associated separator. I.e., no trailing adjacent separators, and no adjacent separators in the middle or beginning either. Are we missing separatorSuppressionPolicy='neverEmpty' or 'anyEmptyStrict' perhaps? Comments? ...mikeb 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

clarification: on suppressed ZL string/hexBinary - do we keep variable assignments?
by Mike Beckerle 02 Aug '18

02 Aug '18

In some situations we parse and get a successful zero-length parse for a string or hexBinary. But because the occurrence is optional, we do NOT add an element to the infoset. In that case, what happens to side-effects that occurred during the successful parse. There are two possible kinds of side-effects. Variables can be set, and a discriminator can be set to true. It seems to me that if a discriminator is set, then that *must* be preserved, and in that case it would seem the variable settings should be retained as well. 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 6

Clarification needed: 14.2.2 Parsing Sequence Groups with Separators - Rep(N)
by Mike Beckerle 01 Aug '18

01 Aug '18

In 14.2.2 the phrase: * Rep(M)* means M occurrences of nil, empty, normal or absent representation. These are optional occurrences so default rules do not apply for empty representations. Begs the question of what happens if the empty representation is not the same as absent representation due to initiators and/or terminators being required by emptyValueDelimiterPolicy. If the empty representation is found, what would a Parser do? These are optional, so defaulting is not applicable. Treat it as "absent" is one possibility, Treat it as "normal" which is likely to result in a parse error, is another. 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

Clarification: empty sequence - how can it be non-zero content length
by Mike Beckerle 01 Aug '18

01 Aug '18

Section 14.1 states: It is a processing error if the SequenceContent region of an empty sequence has non-zero length when parsing. How is it possible for an empty sequence to have a non-zero length of its content region? I understand it could have delimiters outside the content region, and other framing possibly, but the content region has nothing in it then only annotations can appear. Annotations can be property definitions or can be DFDL statements. None of those can consume representation bits when parsing, or produce representation when unparsing. So I believe this processing error cannot happen. If I am correct, the statement about processing error should be dropped. Also, clearly this statement does not apply to a sequence that carries a dfdl:hiddenGroupRef, since the hidden group can contribute to the content region. I would not consider a sequence carrying hiddenGroupRef to be empty unless the referenced group is also empty. 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

typographical - fn:string(...) should be xs:string(...)
by Mike Beckerle 10 Jul '18

10 Jul '18

The DFDL expression language supports the string(...) function in the xs (xml schema) namespace, not the fn (xpath functions) namespace. A few places in the spec use fn:string(...). These need to change to xs:string(...) I've added this to issue https://redmine.ogf.org/issues/233 which is the one of typographical errors. 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 0

Due to holidays the next OGF DFDL WG Call is 7th August <eom>
by Steve Hanson 12 Jun '18

12 Jun '18

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

1 0

Cancelled: OGF DFDL Working Group Call
by Steve Hanson 12 Jun '18

12 Jun '18

1 0

OGF Redmine is down for me currently
by Mike Beckerle 06 Jun '18

06 Jun '18

In case anyone is trying to access DFDL workgroup trackers or docs, the OGF redmine is down at the moment. I'm getting a "Ruby on Rails application could not be started" page. ...mikeb 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