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. )
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.
)
Both our sessions are on Monday Oct 3rd, Session #1 is a working group meeting - 2005-10-03 11:00:00 Beacon Hill Room Session #2 is overview and status - 2005-10-03 14:00:00 Berkeley/Clarendon Room These are US EDT time zone which is UTC-4. So for our F2F meeting, I figure we meet Monday the 3rd at 9am at IBM Copley Place room 101 (I will send step-by-step directions), and meet for an hour and a half. We can review agenda and plan our time maybe kill off a few issues from our issues list. We'll continue discussions in our first session which is a WG session at the Park Plaza Hotel. We'll spend the majority of monday at the Park Plaza down the street until after session 2 ending at 15:30. This session might not take the full 90 minutes so we may have a usable time block afterwards. Tuesday and Wednesday we have 9am to 5pm booked at IBM Copley same room. We should be able to do conference calls for both the Session 1 at the park plaza and any meetings at the IBM facility. I think we need to work on the agenda for our F2F, what topics we'll be covering when both for session 1 at the Park Plaza, and for subsequent sessions on tuesday and wednesday. Given that we'll have callers from the UK on the line potentially, I think it will be good to put certain topics in the morning so they fall in daytime in the UK. At our call this week let's start discussions about the F2F meeting agenda. ...mikeb
participants (2)
-
Martin Westhead -
Mike Beckerle