I will be unable to make the call on 3/3, so here are my comments on Tim's issues. (None of which seem so major to me :-)
4 Tim's (major) issues with draft 039
12.2 Delimiters: Text Markup
- The term 'Delimiters' is not accurate. Most readers will not think of an initiator as a 'delimiter'.
- It's not 'Text' markup any more - especially since v0.39 has allowed lengthKind="delimited" for elements with binary representation.
Title should be 'Markup' and explanation can then deal with what it really is, rather than justifying the innaccurate title :-)
I dislike the use of the term "markup" for something not written by people, and most data formats of the DFDL kind are written by computers, so nothing is getting "marked up" by anyone.
Initiators certainly are delimiters in the situations where they are not tags. I.e., initiator="[" terminator="]". Only tags will not be thought of as delimiters. Even then I think it is a stretch to say that nobody will think of an introductory tag as a delimiter.
These definitions found online:
de·lim·it·er
(dĭ-lĭm'ĭ-tər) 
n. Computer Science A character or sequence of characters marking the beginning or end of a unit of data. |
These definitions are consistent with our usage of the term.
I suggest no change in our terminology here.
Syntax for specifying markup:
It's not clear from this description that each item in the space-separated list is a DFDL string literal.
These have always bugged me. Any better solution is welcome. XML/XSD does tend to make space separated the standard way to specify more than one thing.
initiator ( and all other space-separated properties )
It is not clear whether the order of the space-separated properties matters. Must the parser test them in the order in which they are specified?
( Q: What if %ES; is the first in the list? )
I think the order should not matter, and it should test them longest first.
terminator:
is it OK if the final terminator is missing within the scope of a known-length parent? Seems like a reasonable extension of the rule ( in all other scenarios, the end of a known-length parent acts like the end of the data stream for items with its scope ).
I believe this should be true. "Final" is relative in my mind.
documentFinalTerminatorCanBeMissing:
Let's try to avoid creating another property for the postfix separator scenario. I think this property provides a way of modelling the data naturally.
We can recommend use of infix-with-a-terminator rather than 'postfix' if the final terminator can be missing.
Copasetic.
outputNewLine
Should we validate that the 'characterOrCharacters' are all newline characters from the set described by the %NL; mnemonic? Otherwise the DFDL serializer will output data which cannot be parsed by the DFDL parser.
Nice catch.
dfdl:lengthKind endOfParent
'endOfParent' has almost the same meaning as 'delimited' so should have the same semantics.
· the item’s terminator (if specified)
· an enclosing construct’s separator or terminator
· the end of an enclosing construct designated by its known length
· the end of the data stream
The effect would be the the element could be ended by the nearest known length parent not just the immediate parent. Also the immediate parent could have lengthKind 'implicit'
Agreed.
choiceKind 'Fixed'
When lengthKind='implicit' all alternative branches of the choice are padded to the fixed length of the largest one so that overall the entire choice construct is fixed length
There must be a restriction that the length of at least one choice must be statically defined.
Also good catch.
...mikeb