Re: [DFDL-WG] A selection of example data formats
Hi Mike
More replies but this time I'll keep them together here as the Word doc
would get hard to read....
Tim and I have been thinking on similar lines as your "have enough
properties to determine that the length is zero". In addition to your
examples there are also:
- lengthKind="prefixed" and prefix length is 0
- lengthKind="explicit" and lengthCount expression evaluates to 0
Using the same sectioning as the document...
-------------------------------------------------
a) Fixed length, no delimiters
We agree that there should be no defaulting when the length is > 0.
Need to decide whether the length = 0 case implies defaulting, we think it
does as the property determines that the length is zero
b) Fixed length, only parent has delimiters
This boils down to whether we need to detect early termination. Spec and
yourself are clear that scanning is off when parsing fixed length. I'd
like to hear what Steph has to say on this.
c) Fixed length, initiators
You want to treat this the same as un-initiated fixed length. OK, but more
on this later under i)
e) Delimited, separators required
We agree that defaults should be applied when adjacent separators
encountered
f) Delimited, separators suppressed at end
We agree that defaults should be applied when adjacent separators
encountered and at the end
g) Delimited, initiators, separators required
We agree that defaults should be applied when adjacent separators
encountered
i) Delimited, initiators, separators suppressed
You want defaults to be applied when an element is entirely absent (B in
the example)
Tim and I struggle to differentiate this case from c). At the start of B
processing, there is nothing in the data to indicate B and the next thing
is C's initiator. So why is the defaulting rule different?
Take this one step further - my data is fixed length, initiated and the
parent has a suppressed separator - so which of c) and i) applies?
How does the parser know when a group has ended?
One of Tim's rules was when an enclosing delimiter is found. That is not
always the case. Tim suggested that if the immediate parent had
lengthKind="implicit" then we would not be looking for delimiters. I
believe your YES was agreeing with that? We would say it is also true if
the immediate parent had lengthKind = "explicit" or "pattern" too.
What is the algorithm for selecting the next occurrence?
Tim and I discussed this, and there is not an issue here. The
occursCountKind always tells you the number to expect (which might be
'don't know' if occursCountKind = "parsed" in which case we just
speculatively parse).
When parsing a group with separatorPolicy=suppressed, is every group
member a 'point of uncertainty'?
Agree with your statement.
----------------------------------
Other things to discuss:
Defaulting complex elements when parsing
The spec says that if zero length content is obtained for a complex
element then it is defaulted, which means the element's complex type is
walked and default values are sent to the infoset for required elements.
It is an error if any required elements do not have a default value. A
simpler alternative is to create just the element in the infoset with no
children, but this would fail validation if switched on.
Separator position
Any rules that we agree on must take into account infix v prefix v
postfix. In practice this determines how an element is 'bound' to a
separator. Prefix it is bound to the beginning, postfix it is bound to the
end, infix it is bound to the beginning except for the first element (need
to check with Steph is that is how WTX does it).
Regards
Steve Hanson
Architect, Data Format Description Language (DFDL)
Co-Chair, OGF DFDL Working Group
IBM SWG, Hursley, UK
smh@uk.ibm.com
tel:+44-1962-815848
From:
"Mike Beckerle"
participants (1)
-
Steve Hanson