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

[Martin Westhead]

Sorry I missed the meeting this week.

I have updated the issues list according to these notes from Mike and 
added a new tracker.

I have a small process question to raise: several of the smaller items 
require edits to the document. The issue is just ensuring that these 
edits are made. Several of them are straightforward and could be done by 
a number of people, others may require the author of that part of the 
document to do correctly. For now I have left such items as "pending" in 
the issues list.

Cheers,

Martin

Mike Beckerle wrote:
> 
> 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.
> 
> )
>