[dfdl-wg] minutes of call 2005-09-14

[Mike Beckerle]

Who: Jim Myers, Mike Beckerle, Tara Talbott, Steve Hanson, Geoff Judd, Bob 
McGrath

Agenda:

GGF plans - we will have F2F at GGF15. The schedule of our WG sessions at 
the GGF15 are not yet set, but we'll have F2F meetings during the 
non-scheduled times. We're counting on the fact that most of our DFDL WG 
members are focused on DFDL and won't mind the conflict with the rest of 
GGF15 much. People should make travel plans for all 3 days M, T, W.

GridForge Forums - these seem to be working now. Will try them when one of 
our subcommittees reports back to the broader WG. E.g., scoping or arrays. 


Issues list - we made it through items 5 to 15

Issue 5 - resolution. No built-in set of defaults. If you need a property 
and your configuration doesn't have one specified then it is an error.
There is a small set of named configurations provided with DFDL each of 
which is a self-consistent set of properties. This is probably the set 
that we find useful in the primer and other WG docs.

Issue 6 - resolution. change attribute name from 'base' to 'extends'

Issue 7 - belongs on same tracker as 8, 9, 10

Issue 11 - resolution: add an attribute 'byteOrderMarkPolicy' values are: 
required, notAllowed, optionalButGenerateOnOutput, optionalButOmitOnOutput
(the generate on output control aspect was not discussed on the call. I 
thought of that just now while typing.)

Issue 12 - fix diagram - omission of these types was unintentional. Better 
diagram next draft

Issue 13 and 14 - new tracker item - Steve Hanson, Geoff Judd and someone 
from MikeB's team at IBM to address

Issue 15 - resolution: each delimiter will grow an extra rep-property for 
its regexp variant. E.g., separator will have corresponding 
separatorRegexp property. Only one of the two may be specified. 

We discussed that separator (or any delimiter) can be a text string, and 
we had previously decided that the separatorEncoding attribute would go 
away to be replaced by a syntax for expressing hex bytes (not hex 
character codes, real non-charset transformed hex bytes) as part of 
delimiter strng literals. This same way of putting hex bytes would also be 
supported as part of the regexp language so that the regexp language 
remains able to include any non-regular expression for a delimiter into a 
regular expression. 

(Editor's Note: this is a bit tricky. We now have in string literals 3 
different escape mechanisms that are different.

1) XML character code specifiers e.g., 'abc,def' which is the normal 
XML way of specifying the unicode #x2C character code. (This is an XML 
standard escape convention.) Used inside a delimiter string this means 
take the unicode #x2c code point, figure out what character it corresponds 
to in the charset of the data element and use that character. Note that 
this is the same thing that 'a' means. Take the 'a' unicode code point, 
figure out what character corresponds to 'a' in the charset of the data 
element, and look for that.

2) nonXML character code specifiers e.g., 'abc\#x00;def' which is the way 
we allow you to put XML-disallowed unicode character codes like #x00 into 
a string literal. (This is a DFDL convention). The interpretation here is 
exactly like the above. I.e., '\#x2c;' is exactly equivalent to ',' 
and the charset mapping applies as above. This rule is only needed because 
of the XML restriction disallowing certain unicode character codes from 
the XML infoset. 

3) non-character byte specifiers. E.g., 'abc\%01;\%02;def' which is a 
proposed escape syntax that means put the bytes #x01 and #x02 into the 
string literal bypassing any considerations of charset, i.e., without 
considering them to be character codes in any character set. That is, 
these byte values have nothing to do with unicode codepoint values. (This 
is a DFDL convention.) The other characters of the string would be treated 
as per (1) and/or (2) above. 

)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/dfdl-wg/attachments/20050914/3a9ac585/attachment.htm