[DFDL-WG] Agenda for OGF DFDL WG call 3 March 2010- 13:00 UK (8:00 ET)

[Mike Beckerle]

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)
<http://dictionary.reference.com/help/ahd4/pronkey.html>

n.   *Computer Science*
A character or sequence of characters marking the beginning or end of a unit
of data.

  Computing Dictionary

*delimiter* character
A character <http://dictionary.reference.com/browse/character> or
string<http://dictionary.reference.com/browse/string>used to separate,
or mark the start and end of, items of data in, e.g., a
database <http://dictionary.reference.com/browse/database>, source
code<http://dictionary.reference.com/browse/source+code>,
or text file <http://dictionary.reference.com/browse/text+file>.
See also: record <http://dictionary.reference.com/browse/record>.
(2001-03-16)
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


>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/dfdl-wg/attachments/20100302/9eb9393b/attachment-0001.html