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

Tue Feb 9 11:17:57 CST 2010

1. Comments of latest discriminators doc.

2. Remaining 037 review issues

16.2 scannablility with lengthKind pattern: 
Confirm that this is what we agreed
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.

·         Tracker Issue: [schema] is an absolute or relative SCD. Why 
bother allowing absolute? 
·         Tracker Issue: Glossary as the place for centralized 
definitions, or should they be repeated there, but also introduced at 
point of first use, or should we put the definitions only at the places 
where they are discussed, and xref from the glossary? 
·         TBD: Issue - semantics of expressions containing relative paths 
that are inherited via ref to a dfdl:defineFormat. (also section 10.3)

·         TBD: Issue - XPath term - we are not consistent about using the 
term XPath, or "expression" when referring to our expression language. I 
prefer to call it our expression language, and then in the section that 
defines it state that it is a strict subset of XPath 2.0. 
·         TBD: Issue - fn:position is unclear given that we've just said 
we don't support sequences in the expression language. 
·         TBD: Issue - order of sections. Scoping rules section should 
come before variables section, which uses these concepts. 
TBD: Issue: Case sensitivity of enum names - did we say whether this is 
case sensitive or not? I believe it should be case sensitive. 
·          Issue: dfdl:representation - Strings in binary rep. I see no 
reason why elements of type xs:string will examine dfdl:representation. 
They shouldn?t' care what it is, they are always "text". I should be able 
to specify a bunch of inter-mixed binary number and string elements 
without having to specify dfdl:representation="text' just to avoid an 
error on the string type elements. I believe xs:string type ignores 
dfdl:representation (always behaves as if dfdl:representation is 
'text').(If we change this then the property precedence section for 
simpletypes changes slightly as representation="text" is implied if type 
is string.)
That will make it impossible to introduce a binary representation of text 
later 

What is "a binary representation of text"? Is there a real issue here. 
This is a primary convenience and clarity issue for me. I do not want to 
have to change to representation="text" for every string inside a cobol 
structure, which is ultimately a binary representation object. To me 
type="string" is enough. I want to put in the file scope level of the 
schema a representation="binary", and then decorate the elements with the 
specifics of their types, but I do not expect to have to put 
representation="text" on anything. 

I do not understand what you are trying to achieve by requiring 
representation="text" for things that are already textual based on the 
type. 

The rest of the issues below I think we need to discuss on calls. 
textStringPadCharacter textNumberPadCharacter - did we agree that this 
character must be a "minimum width" character if the char set encoding is 
variable width? (i.e., the pad char must be 1 byte if the encoding is 
UTF-8. 
numberInfinityRep numberNanRep - Is this applicable only to xs:double and 
xs:float? Also, what I've seen requires a distinction of sign. I.e., there 
are positive and negative infinities often printing as -inf and +inf. 
·         TBD: Issue - \n in regular expressions - clarify relationship of 
this to entities like NL entity. Also, if I include an entity like WSP* in 
a regular expression (can I?) does it then match accordingly? 
It appears that some of our multi-valued entities like WSP+ create 
conditional "matching" behavior without having to use regular expressions, 
e.g., when WSP+ is used as a separator. But can you use entities like WSP+ 
in a regular expression? It seems you should be able to use regular 
"single valued" entities in a regular expression, its these multi-valued 
ones that have tricky semantics. 
Added Unicode values to /n, /t,/r.  Disallow DFDL entities in regular 
expressions. 
14.1 Alignment - TBD: Issue - zero-based thinking here. But all the bits 
stuff and everything else in DFDL uses 1-based reasoning. Need to revisit 
to make this sensible for 1 based world. 
Added implicit alignment table. TBD zero-based 
finalTerminatorCanBeMissing - spec is not clear. Also is there a 
finalSeparatorCanBeMissing 
Changed to finalDocumentTerminatorCanBeMissing and  
finalDocumentSeparatorCanBeMissing. Not sure where 
finalDocumentSeparatorCanBeMissing should be specified. Looks odd on 
'distinguished root'. These properties operate differently from other 
properties as they are defined on the 'distinguished root' but affect some 
lower down element. Effectively they are put in scope by a different 
mechanism

3. Go through Actions 

Current Actions:
No
Action 

045
20/05 AP: Speculative Parsing
27/05: Psuedo code has been circulated. Review for next call
03/06: Comments received and will be incorporated
09/06: Progress but not discussed
17/06: Discussed briefly
24/06: No Progress
01/07: No Progress
15/07: No progress. MB not happy with the way the algorithm is documented, 
need to find a better way.
29/07: No Progress 
05/08: No Progress. Will document behaviour as a set of rules.
12/08: No Progress 
...
16/09: no progress
30/09: AP distributed proposal and others commented. Brief discussion AP 
to incorporate update and reissue
07/10: Updated proposal was discussed.Comments will be incorporated into 
the next version.
14/10: Alan to update proposal to include array scenario where minOccurs > 
0
21/10: Updated proposal reviewed
28/10: Updated proposal reviewed see minutes
04/11: Discussed semantics of disciminators on arrays. MB to produce 
examples
11/11: Absorbing action 033 into 045.  Maybe decorated discrminator kinds 
are needed after all. MB and SF to continue with examples. 
18/11: Went through WTX implementation of example. SF to gather more 
documentation about WTX discriminator rules.
25/11: Further discussion. Will get more WTX documentation. Need to 
confirm that no changes need to Resolving Uncertainty doc.
04/11: Further discussion about arrays.
09/12: Reviewed proposed discriminator semantic.
16/12: Reviewed discriminator examples and WTX semantic.
23/12: SF to provide better description of WTX behaviour and invite B 
Connolley to next call
06/01:B Connolly not available. SF to provide more complete description.
13/01: Stephaine took us through a description of WTX identifiers. Mike 
agreed to write up in DFDL terms.
20/01: Mike will write up
27/01: further discussion of discriminators
29/01: Alan had  emailed both proposals but not enough time to discuss
02/02: Agreed to adopt 'component exists' semantics for discriminators
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/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 invetsigating
077
SKK:  mapping of COBOL numbers to textNumberFormats.
03/02: Suman documented the problem. Agreed to remove textNumberFormat and 
textCalendarFormat.
078
MB: Reword section 2.3.1 incorporating markup order rules.

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/20100209/41f0a475/attachment.html 