[DFDL-WG] Agenda for OGF DFDL WG call 3 March 2010- 13:00 UK (8:00 ET)
Alan Powell
alan_powell at uk.ibm.com
Tue Mar 2 12:37:38 CST 2010
1. 16.2 scannablility with lengthKind pattern:
2. Current Actions:
3 Steve H issues with draft 039
4 Tim's (major) issues with draft 039
5 Status of specification (for OGF28)
1. 16.2 scannablility with lengthKind pattern:
In summary, you can use a data pattern on any element (complex, simple
text, simple binary) as long as the bytes are legal in the stated
encoding, which where binary data is involved in practice means an 8-bit
ASCII encoding.
Binary data can be handled using some of the conveniences of text by way
of treating it as text with encoding="iso-8859-1". In this case literal
text, such as length patterns, is interpreted as in the iso-8859-1
character encoding, and the correspondence of byte values in the data to a
string in the DFDL infoset is one to one. That is, byte with value N,
produces an infoset character with character code N.
2. Current Actions:
No
Action
049
20/05 AP Built-in specification description and schemas
03/06: not discussed
24/06: No Progress
24/06: No Progress (hope to get these from test cases)
15/07: No progress. Once available, the examples in the spec should use
the dfdl:defineFormat annotations they provide.
...
14/10: no progress
21/10: Discussed the real need for this being in the specification. It
seemed that the main value is it define a schema location for downloading
'known' defaults from the web.
28/10: no progress
04/11: no progress
11/11: no update
18/11: no update
25/11: Agreed to try to produce for CSV and fixed formats
04/12: no update
09/12: no update
16/12: no update
23/12: no update
06/01: no progress. If there is no resource to complete this action it can
be deferred
13/01:no progress
20/01: no progress
27/01: no progress
29/01: No progress. The predefined formats do not need to be available
when the spec is published.
Suman said that he had been mapping COBOL structures to DFDL and it didn't
look as though the way text numbers are define is very usable. He will
document for next call
03/02: No progress
10/02: No progress
17/03: No progress
24/03: No progress
066
Investigate format for defining test cases
25/11:IBM to see if it is possible to publish its test case format.
04/12: no update
09/12: no update
16/12: reminded dent to project manager
23/12: SH will send another reminder.
06/01: Another reminder will be sent
13/01: no update
20/01: no update
27/01: no progress
29/01: no progress
03/02: IBM is still investigating
10/02: IBM is still investigating
17/02: IBM is willing in principle to publish the test case format and
some of the test cases. May need some time to build a 'compliance suite'
24/03: No progress
079
MB:Encoding for binary fields when lenghtkind is pattern
17/02: Discussed but no conclusion
24/03: Mike has found an encoding that matches the first 255 codepoints of
iso 10646. Will document its use for binary fields.
080
AP:Clarify semantics of fn:poisition and fn:count
17/02: no progress
24/03: No progress
083
MB:To correct syntax diagram for FinalUnused and suggest wording for the
Sequence section
3 Steve H issues with draft 039
1) Name of property dfdl:textNumberRepresentation is not consistent with
dfdl:binaryNumberRep, dfdl:binaryFloatRep, etc.
2) The dfdl:numberPattern etc properties that have been moved from the
defunct dfdl:textNumberFormat annotation to dfdl:element etc should be
called dfdl:textNumberPattern etc. Otherwise users will think they apply
to binary numbers too.
3) In section 14.3 on sequences, there are several sub-sections that talk
about parsing according to different ways of specifying length (ie,
lengthKind). But dfdl:sequence no longer carries dfdl:lengthKind so I
think these sub-sections are not in the right place. I think they should
be in section 12, under the correct 12.3.x lengthKind sub-section.
4) Section 19 on built-in specifications. Given that we don't have any for
public comment phase we should reword this section.
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 :-)
Syntax for specifying markup:
It's not clear from this description that each item in the space-separated
list is a DFDL string literal.
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? )
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 ).
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.
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.
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'
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.
Regards
Alan Powell
Development - MQSeries, Message Broker, ESB
IBM Software Group, Application and Integration Middleware Software
-------------------------------------------------------------------------------------------------------------------------------------------
IBM
MP211, Hursley Park
Hursley, SO21 2JN
United Kingdom
Phone: +44-1962-815073
e-mail: alan_powell at uk.ibm.com
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/dfdl-wg/attachments/20100302/ae928b69/attachment.html
More information about the dfdl-wg
mailing list