- dfdl-wg - lists.ogf.org

DFDL expression language
by Alan Powell 06 Feb '08

06 Feb '08

All Latest version of the dfdl expression language. As a result of the comment received I have added a section with a formal description of the syntax and removed the equivalent word sections. The syntax was extracted from the XPath spec and unnecessary sections removed. This doc has been included in the latest version of the full spec. Alan Powell MP 211, IBM UK Labs, Hursley, Winchester, SO21 2JN, England Notes Id: Alan Powell/UK/IBM email: alan_powell(a)uk.ibm.com Tel: +44 (0)1962 815073 Fax: +44 (0)1962 816898 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

1 0

DFDL: mikeb unable to make call this week
by Mike Beckerle 06 Feb '08

06 Feb '08

Sorry folks, I did work with Steve on nulls/defaults, and that's in to Alan for integration I believe (yes steve?) I also did my work reviewing the expression language draft. I tried to write the calculated elements (inputValueCalc &c) section. Small improvements sent to alan, but there's more to do here still. I need the slides from the last OGF to prepare for the one here in Cambridge MA later in Feb. I am registered now. .mikeb

2 1

DFDL: Minutes from OGF WG call, 30 Jan 2007
by Ian W Parkinson 01 Feb '08

01 Feb '08

All, Here are the minutes from Wednesday's meeting - apologies for the delay. As ever please let me know of any corrections. Cheers, Ian Open Grid Forum: Data Format Description Language Working Group Weekly Working Group Conference Call 17:00 GMT, 30 Jan 2008 Attendees Mike Beckerle (Oco) Steve Hanson (IBM) Geoff Judd (IBM) Suman Kalia (IBM) Simon Parker (PolarLake) Ian Parkinson (IBM) Alan Powell (IBM) 1. Specification drafts Alan has not yet received any updates for the next draft of the specification, which is due soon. As Alan is on vacation from the end of next week, he is looking for input as soon as possible. The group recorded the following status for items targetting for the next specification draft: Nulls/default/optionals - Mike and Steve will collaborate on this and hope to have a draft ready for the end of next week. Description of schema components - Simon expects to have this ready by the end of the week.. Regular expressions for lengths - This is now targeted for the following specification draft ("vX+2") Expression language - Alan has distributed a new draft for review and has asked for comments. Mike will review this next week. valueCalc - Mike will write up at least a first draft, and aims to have this ready for next week. Property precedence - Steve is looking for review comments on the previously distributed mindmap. The specification can include this information simply as a list, not as a "mindmap" tree. It may be useful to combine this information with the schema components diagram. The present proposal only handles parsing; Steve will extend this to cover unparsing. Entities - The group has been having good discussions regarding the entities proposal. White space handling - Whitespace seems to be largely handled by the entities proposal. Steve has been thinking about a way to introduce variable terminators to DFDL, which is discussed later in the meeting. 2. Expression Language Alan distributed a new draft of the expression language proposal, and thanks Simon for his comments. As noted above, Mike will send review comments next week. The second part of the proposal document is text from the current specification draft, which will be replaced by the new proposal. This is included for "history" and is not intended to be reviewed. 3. Whitespace The MIME header format allows for optional whitespace either side of a colon used to delimit the header name and its value. Steve felt that this justfied the need for the proposed %OWSP; entity (along with the %WSP; entity). Mike wondered whether this lead to a slippery slope where we try to handle other complex delimiters similarly, for example, case-insensitive delimiters. Steve would like to propose a more general way to handle complex delimiters in DFDL. Mike would have no objection to having both %WSP; and %OWSP; in the language if these could be described in terms of Steve's more general approach. In PolarLake, the MIME header use case would be handled using a name field (terminated by a colon), with a optional field between the colon and the value which would consume any whitespace. 4. Recursive definitions for delimeters Steve has proposed describing initiators in terms of named types. For example, an intiator could be defined using a simple enumeration type to list its possible values, or one using a pattern facet or assertions. This would extend DFDL's current use of such facets, which are presently used only for validation. Mike distinguished between 'format' and 'content' data, and suggested that this conceptually means that we can interpret facets during parsing for format data, but only at validation for content. Simon suggested a similar concept of "system data" vs. "user data". We would need to revisit speculative parsing to deal with this issue. An alternative, suggested by Simon, would be to relax the present restriction which allows an expression to only return one value. If an expression could return a sequence of values, as is allowed by XPath, then we could use expressions to describe delimiters with multiple possible values. On output, a DFDL unparser would write out the first value in the sequence. Mike observed that such a scheme would solve the 'quoting hell' problem present with simple, space-delimited, XML lists as presently allowed for the nullValues property. If we adopt Steve's approach, we may not be able to access DFDL constructs (variables, expressions or entities) in facets. Steve pointed out that XSD processors would typically reject an enumerated type, restricted to length 1, where the enumeration includes a DFDL entity - the XSD processor will not recognise the DFDL entity and instead treat this as a string of length greater than 1. Alan asked whether there are any dynamic cases, where the set of terminators is obtained from the document itself. Mike felt that this could be modelled using assertions, though this would leave terminator on output undefined; and that a solution where complex types may be used as terminators would probably allow us to handle most of these cases. Steve mentioned the EDI format, which allows a document-specified delimiter to be used with optional whitespace. How, asked Simon, should we handle the output value of a complex delimiter? This must come either from the DFDL schema or from the infoset. Steve suggested we use default properties in the subelements of the type, and Mike suggested we could similarly use outputValueCalc. Steve and Mike agreed that a terminator wouldn't be present in the infoset, by analogy to the similar mechanism used for length prefixes. Further, this mechanism might allow us to remove a number of properties related to terminators. Although Steve had intended this mechanism to be used with simple types or elements, Mike and Suman thought it would be appropriate to allow complex types. Elements would allow the use of the 'default' attribute for use on output. Mike contrasted this to the prefix length solution, where a simple type is used: the value under prefix length is treated as an integer, so it is appropriate to handle it as such. Here, however, we are modelling syntactic constructs. Simon felt that users will think in terms of elements. Steve will prepare some examples and a proposal for inclusion in the "vX+2" draft. 5. Other business Simon will email the group with some questions about the UML schema components description. Meeting closed, 18:10 GMT Ian Parkinson WebSphere ESB Development Mail Point 211, Hursley Park, Hursley, Winchester, SO21 2JN, UK 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

1 0

DFDL schema abstract data model 3
by Simon Parker 31 Jan '08

31 Jan '08

Good evening. Here are diagrams and accompanying words, as promised. This isn't final, and I would welcome feedback to help me finish it off. Dash off a quick email, or mark up the document with comments and tracked changes, or ring me, according to your own preference. Hope this helps, Simon Simon Parker Software Consultant PolarLake 80 Harcourt Street Dublin 2, Ireland Phone +353 1 449-1075 Fax +353 1 449-1011 Web http://www.polarlake.com/ The information transmitted in this email is intended for the addressee only and may contain confidential and/or privileged material. Any review, retransmission, dissemination, reliance upon or other use of this information by persons or entities other than the addressee is prohibited. If you think, for any reason, that this message may have been addressed to you in error, we would ask you to notify the sender immediately by return email and delete the material. PolarLake Limited | Registered in Dublin, Ireland | Number 357324 | Registered office as above.

1 0

Agenda for DFDL WG call - 2008-01-30
by Mike Beckerle 30 Jan '08

30 Jan '08

Thanks Alan and Steve for some agenda topics: Follow up the items from last week - Specification drafts - I need updates from everyone to produce next spec draft - Expression language - Comments from only Steve H. so far - Property precedence - Any more comments/discussion - UML for DFDL schema - status update - Entity proposal updates? Discussion for this call - White space - Steve's items (??) - OGF presentation Other Topics? From: Steve Hanson [mailto:smh@uk.ibm.com] Sent: Tuesday, January 29, 2008 1:10 PM To: Mike Beckerle Cc: Alan Powell Subject: Agenda for DFDL WG call Hi Mike - possible agenda items for tomorrow. Regards, Steve Steve Hanson WebSphere Message Brokers Hursley, UK Internet: smh(a)uk.ibm.com Phone (+44)/(0) 1962-815848 ----- Forwarded by Steve Hanson/UK/IBM on 29/01/2008 17:55 ----- Alan Powell/UK/IBM 29/01/2008 17:25 To Steve Hanson/UK/IBM@IBMGB cc Subject Fw: [DFDL-WG] DFDL: Minutes from OGF WG call, 23 Jan 2007 *CORRECTED* Steve I will try to make the WG call tomorrow but may be still on a course. We need to follow up the items from last week - Specification drafts - I need updates from everyone to produce next spec draft - Expression language - Comments from only you so far - Property precedence - Any more comments/discussion - UML for DFDL schema - status update - Entity proposal - I should have updated as a result of last weeks discussion but haven't had time Discussion for this call - White space - Your items. We did discuss them a bit but mostly in the context of white space. Alan Powell MP 211, IBM UK Labs, Hursley, Winchester, SO21 2JN, England Notes Id: Alan Powell/UK/IBM email: alan_powell(a)uk.ibm.com Tel: +44 (0)1962 815073 Fax: +44 (0)1962 816898 ----- Forwarded by Alan Powell/UK/IBM on 29/01/2008 17:19 ----- Steve Hanson/UK/IBM@IBMGB Sent by: dfdl-wg-bounces(a)ogf.org 28/01/2008 08:51 To dfdl-wg(a)ogf.org cc Subject Re: [DFDL-WG] DFDL: Minutes from OGF WG call, 23 Jan 2007 *CORRECTED* Sorry I couldn't make the call. Some comments: a) we need both WSP and OWSP if DFDL delimiter properties can only specify a single value. If they can specify a list of values then you can get away with only needing WSP eg, dfdl:terminator="@ @%WSP;" b) if we make WSP mean a single white space character, we need a second entity for multiple white space characters. It doesn't look like you got round to discussing the other items I sent in (below)? Let's do that next call. 1) One way to handle the situation where the terminator can vary is to allow the DFDL markup properties (dfdl:terminator, dfdl:separator, etc) to be lists, just like we already do for dfdl:nullValues. (IBM's WTX has this capability). 2) We've allowed the prefix of a prefixed length to be explicitly described as a non-event field using dfdl:lengthPrefixType. Should we permit this for markup properties? Instead of supplying a list of possible values, you supply a simple type with enums for the values. This could be viewed as an alternative/complementary to 1). There is a limitations - because we are using XSDL enumeration facet, we are constrained by its syntax so I don't see how we could use our own entity scheme or expressions. Also, I suspect that enums are inherently unordered so we'd need a way of saying which to use on output (use an element of simple type and use XSDL default attribute?). Lastly, we should not force a user to model an initiator as an element/type - most users just see it as a piece of text so just entering the value must still be allowed. 3) Let's say my delimiter is dynamically defined at the start of the data, like EDI allows. We would handle that in DFDL using an expression or variable. However, EDI also allows random white space to appear after the delimiter. Can our expression/entity syntaxes handle this? Does this preclude use of 1) or 2)? Regards, Steve Steve Hanson WebSphere Message Brokers Hursley, UK Internet: smh(a)uk.ibm.com Phone (+44)/(0) 1962-815848 Ian W Parkinson/UK/IBM@IBMGB Sent by: dfdl-wg-bounces(a)ogf.org 24/01/2008 16:19 To dfdl-wg(a)ogf.org cc Subject [DFDL-WG] DFDL: Minutes from OGF WG call, 23 Jan 2007 *CORRECTED* A small correction. with thanks to Simon - it was Steve (rather than Simon) who had previously attracted a reasonable audience at the OGF conference. Ian Open Grid Forum: Data Format Description Language Working Group Weekly Working Group Conference Call 17:00 GMT, 23 Jan 2008 Attendees Mike Beckerle (Oco) Simon Parker (PolarLake) Ian Parkinson (IBM) Alan Powell (IBM) Apologies Steve Hanson (IBM), Suman Kalia (IBM) 1. OGF22 The DFDL session at OGF22 is now booked for the Monday afternoon, and Mike has registered to attend. Mike will present our updated status, and Alan promised to upload the last set of presented slides to GridForge so that Mike can update them. Alan asked whether we should attempt to drum up interest in the DFDL session to encourage attendence; Simon thought that advertising may not make much difference and that Steve had a reasonable audience when he presented. 2. Specification drafts Steve and Alan had previously assigned ownership of individual items from Mike's plan of contents for the next few drafts. Alan will assemble the next draft, due at the end of the month, and asked for input as soon as possible. Looking at the plan for the next, "vX+1", draft, the group reported the following status: * Nulls/default/optionals - Mike reported no update. * Description of schema components - Simon is still working on this. * Regular expressions for lengths - Alan reported no progress. * Expression language - Alan will shortly distribute a new version of the proposal for review. * valueCalc - Mike is still to write this. * Property precedence - Following a discussion on the call last week, please provide review comments. Mike will add this to the agenda for next week. * Entities - Alan's recent proposal is to be discussed on the current call. * White space handling - Discussion is ongoing, and Steve is to make a proposal. The plan calls for subsequent versions of the specification, including the following items with status: * Supplements - Steve is working to update the supplements * Speculative parsing - IBM has internally been discussing and reviewing WTX function, though no documentation presently exists covering this. 3. UML diagrams Simon is revising the UML diagrams which describe the DFDL schema components. The previous meeting minutes included a number of comments on these diagrams, and the group took this opportunity to look at some of those comments: "...I think it would be better to use the open source XML schema model as source model and show relationship of DFDL Annotations attached to the XSD schema model" - Mike noted that DFDL makes use of annotations on objects which are absent from the XSD schema model, and hence that it may be unnatural to base the DFDL schema model directly on the XSD model. Simon suggested that it would be cleanest to describe a modified version the XSD model including those XSD elements that we need to annotate, and use this as a basis for the DFDL model. "The current diagram suggests that 'variable definition' can both be part of a format base or as a standalone annotation (outside of a format). Is this true?" - Mike suggested that variable definitions don't have to be part of a format block: so, yes, this is true. Mike agreed to respond further to the set of comments by email. 4. Review of Entities proposal Alan has distributed a proposal covering entities in DFDL, intended to allow characters which are disallowed by XML1.0 (or XML1.1) to be included in DFDL schemas. These follow a similar syntax to XML, using % instead of & as an escape, with an additional mechanism for specifying raw data. This latter is intended to supplant the escaping mechanism described in current versions of the specification (which also uses % as an escape). The group felt that the description of the raw data entities should not be cast in terms of characters and character sets, but rather in terms of bytes. If treated as characters, schemas may need to be written when moving from single-byte to double-byte character sets; further, this incorrectly implies some codepage conversion is involved. The proposal also introduces a list of predefined names for certain common control characters. Mike asked whether these are the existing XML names - Alan replied that XML does not define names for control characters. Ian asked how we should represent the literal % character in strings given this form of escaping. The present draft of the specification uses "%%" to handle this; Simon suggested a string like "%pc;". The meeting felt that %% might be marginally preferable. Finally, the proposal defines some labels which aim to reduce the complexity of dealing with whitespace and newlines. The %NL; entity represents a newline on "the target platform" - Mike observed that DFDL presently does not have a concept of a target platform. Alan felt it important that a single DFDL schema be able to generate output documents targetted at different platforms. Mike proposed that we introduce a new property, "generatedNewLine", which describes the meaning of %NL; during unparse, and that %NL; should be tolerant of any common new line representation during parse. The group discussed whether this could instead be handled using a list of optional new line values, however this would not support schema portability. Simon suggested we introduce another new property to mean that %NL; should be the conventional new line representation on the platform on which an engine is running, however Mike pointed out that this simply requires appropriate configuration of the generatedNewLine property. %WSP; and %OWSP; are introduced to mean any whitespace, and optional whitespace. This will be useful in describing some formats which allow arbitrary whitespace, such as MIME. Mike pointed out that we could model such whitespace using hidden fields, but that these entities may make a schema clearer. PolarLake have found that only one such label is necessary, which means, "one or more whitespace characters", and that this needs only to be made available as a delimiter - Mike agreed that this label may represent a special type of delimiter rather than a general purpose entity. Alan would like to work through the potential use cases to see if we can restrict it in this fashion, and will update the proposal to specify that these relate to just one character. Simon suggested we could introduce an extra label, perhaps %WPS*; to match multiple whitespace characters. Meeting closed, 18:15 Ian Parkinson WebSphere ESB Development Mail Point 211, Hursley Park, Hursley, Winchester, SO21 2JN, UK _____ 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 -- dfdl-wg mailing list dfdl-wg(a)ogf.org http://www.ogf.org/mailman/listinfo/dfdl-wg _____ 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 -- dfdl-wg mailing list dfdl-wg(a)ogf.org http://www.ogf.org/mailman/listinfo/dfdl-wg _____ 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

2 1

Expression language: feedback
by Simon Parker 30 Jan '08

30 Jan '08

Good morning. I embedded a couple of corrections and comments. Regards, Simon Simon Parker Software Consultant PolarLake 80 Harcourt Street Dublin 2, Ireland Phone +353 1 449-1075 Fax +353 1 449-1011 Web http://www.polarlake.com/ The information transmitted in this email is intended for the addressee only and may contain confidential and/or privileged material. Any review, retransmission, dissemination, reliance upon or other use of this information by persons or entities other than the addressee is prohibited. If you think, for any reason, that this message may have been addressed to you in error, we would ask you to notify the sender immediately by return email and delete the material. PolarLake Limited | Registered in Dublin, Ireland | Number 357324 | Registered office as above.

1 0

DFDL: Minutes from OGF WG call, 23 Jan 2007 *CORRECTED*
by Ian W Parkinson 28 Jan '08

28 Jan '08

A small correction. with thanks to Simon - it was Steve (rather than Simon) who had previously attracted a reasonable audience at the OGF conference. Ian Open Grid Forum: Data Format Description Language Working Group Weekly Working Group Conference Call 17:00 GMT, 23 Jan 2008 Attendees Mike Beckerle (Oco) Simon Parker (PolarLake) Ian Parkinson (IBM) Alan Powell (IBM) Apologies Steve Hanson (IBM), Suman Kalia (IBM) 1. OGF22 The DFDL session at OGF22 is now booked for the Monday afternoon, and Mike has registered to attend. Mike will present our updated status, and Alan promised to upload the last set of presented slides to GridForge so that Mike can update them. Alan asked whether we should attempt to drum up interest in the DFDL session to encourage attendence; Simon thought that advertising may not make much difference and that Steve had a reasonable audience when he presented. 2. Specification drafts Steve and Alan had previously assigned ownership of individual items from Mike's plan of contents for the next few drafts. Alan will assemble the next draft, due at the end of the month, and asked for input as soon as possible. Looking at the plan for the next, "vX+1", draft, the group reported the following status: Nulls/default/optionals - Mike reported no update. Description of schema components - Simon is still working on this. Regular expressions for lengths - Alan reported no progress. Expression language - Alan will shortly distribute a new version of the proposal for review. valueCalc - Mike is still to write this. Property precedence - Following a discussion on the call last week, please provide review comments. Mike will add this to the agenda for next week. Entities - Alan's recent proposal is to be discussed on the current call. White space handling - Discussion is ongoing, and Steve is to make a proposal. The plan calls for subsequent versions of the specification, including the following items with status: Supplements - Steve is working to update the supplements Speculative parsing - IBM has internally been discussing and reviewing WTX function, though no documentation presently exists covering this. 3. UML diagrams Simon is revising the UML diagrams which describe the DFDL schema components. The previous meeting minutes included a number of comments on these diagrams, and the group took this opportunity to look at some of those comments: "...I think it would be better to use the open source XML schema model as source model and show relationship of DFDL Annotations attached to the XSD schema model" - Mike noted that DFDL makes use of annotations on objects which are absent from the XSD schema model, and hence that it may be unnatural to base the DFDL schema model directly on the XSD model. Simon suggested that it would be cleanest to describe a modified version the XSD model including those XSD elements that we need to annotate, and use this as a basis for the DFDL model. "The current diagram suggests that 'variable definition' can both be part of a format base or as a standalone annotation (outside of a format). Is this true?" - Mike suggested that variable definitions don't have to be part of a format block: so, yes, this is true. Mike agreed to respond further to the set of comments by email. 4. Review of Entities proposal Alan has distributed a proposal covering entities in DFDL, intended to allow characters which are disallowed by XML1.0 (or XML1.1) to be included in DFDL schemas. These follow a similar syntax to XML, using % instead of & as an escape, with an additional mechanism for specifying raw data. This latter is intended to supplant the escaping mechanism described in current versions of the specification (which also uses % as an escape). The group felt that the description of the raw data entities should not be cast in terms of characters and character sets, but rather in terms of bytes. If treated as characters, schemas may need to be written when moving from single-byte to double-byte character sets; further, this incorrectly implies some codepage conversion is involved. The proposal also introduces a list of predefined names for certain common control characters. Mike asked whether these are the existing XML names - Alan replied that XML does not define names for control characters. Ian asked how we should represent the literal % character in strings given this form of escaping. The present draft of the specification uses "%%" to handle this; Simon suggested a string like "%pc;". The meeting felt that %% might be marginally preferable. Finally, the proposal defines some labels which aim to reduce the complexity of dealing with whitespace and newlines. The %NL; entity represents a newline on "the target platform" - Mike observed that DFDL presently does not have a concept of a target platform. Alan felt it important that a single DFDL schema be able to generate output documents targetted at different platforms. Mike proposed that we introduce a new property, "generatedNewLine", which describes the meaning of %NL; during unparse, and that %NL; should be tolerant of any common new line representation during parse. The group discussed whether this could instead be handled using a list of optional new line values, however this would not support schema portability. Simon suggested we introduce another new property to mean that %NL; should be the conventional new line representation on the platform on which an engine is running, however Mike pointed out that this simply requires appropriate configuration of the generatedNewLine property. %WSP; and %OWSP; are introduced to mean any whitespace, and optional whitespace. This will be useful in describing some formats which allow arbitrary whitespace, such as MIME. Mike pointed out that we could model such whitespace using hidden fields, but that these entities may make a schema clearer. PolarLake have found that only one such label is necessary, which means, "one or more whitespace characters", and that this needs only to be made available as a delimiter - Mike agreed that this label may represent a special type of delimiter rather than a general purpose entity. Alan would like to work through the potential use cases to see if we can restrict it in this fashion, and will update the proposal to specify that these relate to just one character. Simon suggested we could introduce an extra label, perhaps %WPS*; to match multiple whitespace characters. Meeting closed, 18:15 Ian Parkinson WebSphere ESB Development Mail Point 211, Hursley Park, Hursley, Winchester, SO21 2JN, UK 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

2 1

DFDL: Minutes from OGF WG call, 23 Jan 2007
by Ian W Parkinson 24 Jan '08

24 Jan '08

All, Here's my minutes from yesterday's call - please let me know if I've missed anything. As a reminder: there's an archive of the dfdl-wg mailing list (including these meeting minutes) available at < http://www.ogf.org/pipermail/dfdl-wg>. Cheers, Ian Open Grid Forum: Data Format Description Language Working Group Weekly Working Group Conference Call 17:00 GMT, 23 Jan 2008 Attendees Mike Beckerle (Oco) Simon Parker (PolarLake) Ian Parkinson (IBM) Alan Powell (IBM) Apologies Steve Hanson (IBM), Suman Kalia (IBM) 1. OGF22 The DFDL session at OGF22 is now booked for the Monday afternoon, and Mike has registered to attend. Mike will present our updated status, and Alan promised to upload the last set of presented slides to GridForge so that Mike can update them. Alan asked whether we should attempt to drum up interest in the DFDL session to encourage attendence; Simon thought that advertising may not make much difference and that he had a reasonable audience when he presented. 2. Specification drafts Steve and Alan had previously assigned ownership of individual items from Mike's plan of contents for the next few drafts. Alan will assemble the next draft, due at the end of the month, and asked for input as soon as possible. Looking at the plan for the next, "vX+1", draft, the group reported the following status: Nulls/default/optionals - Mike reported no update. Description of schema components - Simon is still working on this. Regular expressions for lengths - Alan reported no progress. Expression language - Alan will shortly distribute a new version of the proposal for review. valueCalc - Mike is still to write this. Property precedence - Following a discussion on the call last week, please provide review comments. Mike will add this to the agenda for next week. Entities - Alan's recent proposal is to be discussed on the current call. White space handling - Discussion is ongoing, and Steve is to make a proposal. The plan calls for subsequent versions of the specification, including the following items with status: Supplements - Steve is working to update the supplements Speculative parsing - IBM has internally been discussing and reviewing WTX function, though no documentation presently exists covering this. 3. UML diagrams Simon is revising the UML diagrams which describe the DFDL schema components. The previous meeting minutes included a number of comments on these diagrams, and the group took this opportunity to look at some of those comments: "...I think it would be better to use the open source XML schema model as source model and show relationship of DFDL Annotations attached to the XSD schema model" - Mike noted that DFDL makes use of annotations on objects which are absent from the XSD schema model, and hence that it may be unnatural to base the DFDL schema model directly on the XSD model. Simon suggested that it would be cleanest to describe a modified version the XSD model including those XSD elements that we need to annotate, and use this as a basis for the DFDL model. "The current diagram suggests that 'variable definition' can both be part of a format base or as a standalone annotation (outside of a format). Is this true?" - Mike suggested that variable definitions don't have to be part of a format block: so, yes, this is true. Mike agreed to respond further to the set of comments by email. 4. Review of Entities proposal Alan has distributed a proposal covering entities in DFDL, intended to allow characters which are disallowed by XML1.0 (or XML1.1) to be included in DFDL schemas. These follow a similar syntax to XML, using % instead of & as an escape, with an additional mechanism for specifying raw data. This latter is intended to supplant the escaping mechanism described in current versions of the specification (which also uses % as an escape). The group felt that the description of the raw data entities should not be cast in terms of characters and character sets, but rather in terms of bytes. If treated as characters, schemas may need to be written when moving from single-byte to double-byte character sets; further, this incorrectly implies some codepage conversion is involved. The proposal also introduces a list of predefined names for certain common control characters. Mike asked whether these are the existing XML names - Alan replied that XML does not define names for control characters. Ian asked how we should represent the literal % character in strings given this form of escaping. The present draft of the specification uses "%%" to handle this; Simon suggested a string like "%pc;". The meeting felt that %% might be marginally preferable. Finally, the proposal defines some labels which aim to reduce the complexity of dealing with whitespace and newlines. The %NL; entity represents a newline on "the target platform" - Mike observed that DFDL presently does not have a concept of a target platform. Alan felt it important that a single DFDL schema be able to generate output documents targetted at different platforms. Mike proposed that we introduce a new property, "generatedNewLine", which describes the meaning of %NL; during unparse, and that %NL; should be tolerant of any common new line representation during parse. The group discussed whether this could instead be handled using a list of optional new line values, however this would not support schema portability. Simon suggested we introduce another new property to mean that %NL; should be the conventional new line representation on the platform on which an engine is running, however Mike pointed out that this simply requires appropriate configuration of the generatedNewLine property. %WSP; and %OWSP; are introduced to mean any whitespace, and optional whitespace. This will be useful in describing some formats which allow arbitrary whitespace, such as MIME. Mike pointed out that we could model such whitespace using hidden fields, but that these entities may make a schema clearer. PolarLake have found that only one such label is necessary, which means, "one or more whitespace characters", and that this needs only to be made available as a delimiter - Mike agreed that this label may represent a special type of delimiter rather than a general purpose entity. Alan would like to work through the potential use cases to see if we can restrict it in this fashion, and will update the proposal to specify that these relate to just one character. Simon suggested we could introduce an extra label, perhaps %WPS*; to match multiple whitespace characters. Meeting closed, 18:15 Ian Parkinson WebSphere ESB Development Mail Point 211, Hursley Park, Hursley, Winchester, SO21 2JN, UK 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

1 0

Fw: OGF DFDL WG call today 23-01-2008 - agenda
by Alan Powell 23 Jan '08

23 Jan '08

Alan Powell MP 211, IBM UK Labs, Hursley, Winchester, SO21 2JN, England Notes Id: Alan Powell/UK/IBM email: alan_powell(a)uk.ibm.com Tel: +44 (0)1962 815073 Fax: +44 (0)1962 816898 ----- Forwarded by Alan Powell/UK/IBM on 23/01/2008 17:18 ----- Alan Powell/UK/IBM 23/01/2008 12:08 To DFDL cc Subject OGF DFDL WG call today 23-01-2008 - agenda Review items from previous calls. - OGF22 - Specification drafts - Expression language - Property precedence - UML for DFDL schema Discussion for this call - Review entity proposal - Steve's suggestions 1) This is related to the white space discussion around entities. One way to handle the situation where the terminator can vary is to allow the DFDL markup properties (dfdl:terminator, dfdl:separator, etc) to be lists, just like we already do for dfdl:nullValues. (IBM's WTX has this capability). 2) We've allowed the prefix of a prefixed length to be explicitly described as a non-event field using dfdl:lengthPrefixType. Should we permit this for markup properties? Instead of supplying a list of possible values, you supply a simple type with enums for the values. This could be viewed as an alternative/complementary to 1). There is a limitations - because we are using XSDL enumeration facet, we are constrained by its syntax so I don't see how we could use our own entity scheme or expressions. Also, I suspect that enums are inherently unordered so we'd need a way of saying which to use on output (use an element of simple type and use XSDL default attribute?). Lastly, we should not force a user to model an initiator as an element/type - most users just see it as a piece of text so just entering the value must still be allowed. 3) Let's say my delimiter is dynamically defined at the start of the data, like EDI allows. We would handle that in DFDL using an expression or variable. However, EDI also allows random white space to appear after the delimiter. Can our expression/entity syntaxes handle this? Does this preclude use of 1) or 2)? Alan Powell MP 211, IBM UK Labs, Hursley, Winchester, SO21 2JN, England Notes Id: Alan Powell/UK/IBM email: alan_powell(a)uk.ibm.com Tel: +44 (0)1962 815073 Fax: +44 (0)1962 816898 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 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

1 0

Fw: Agenda for DFDL WG Call
by Steve Hanson 23 Jan '08

23 Jan '08

I can't make the call today as I am travelling but there are a couple of things I'd like to raise. These have come to light while I have been thinking about white space issues. 1) This is related to the white space discussion around entities. One way to handle the situation where the terminator can vary is to allow the DFDL markup properties (dfdl:terminator, dfdl:separator, etc) to be lists, just like we already do for dfdl:nullValues. (IBM's WTX has this capability). 2) We've allowed the prefix of a prefixed length to be explicitly described as a non-event field using dfdl:lengthPrefixType. Should we permit this for markup properties? Instead of supplying a list of possible values, you supply a simple type with enums for the values. This could be viewed as an alternative/complementary to 1). There is a limitations - because we are using XSDL enumeration facet, we are constrained by its syntax so I don't see how we could use our own entity scheme or expressions. Also, I suspect that enums are inherently unordered so we'd need a way of saying which to use on output (use an element of simple type and use XSDL default attribute?). Lastly, we should not force a user to model an initiator as an element/type - most users just see it as a piece of text so just entering the value must still be allowed. 3) Let's say my delimiter is dynamically defined at the start of the data, like EDI allows. We would handle that in DFDL using an expression or variable. However, EDI also allows random white space to appear after the delimiter. Can our expression/entity syntaxes handle this? Does this preclude use of 1) or 2)? Regards, Steve Steve Hanson WebSphere Message Brokers Hursley, UK Internet: smh(a)uk.ibm.com Phone (+44)/(0) 1962-815848 ----- Forwarded by Steve Hanson/UK/IBM on 23/01/2008 08:27 ----- "Mike Beckerle" <mbeckerle.dfdl(a)gmail.com> Sent by: dfdl-wg-bounces(a)ogf.org 23/01/2008 04:18 To dfdl-wg(a)ogf.org cc Subject [DFDL-WG] Agenda for DFDL WG Call I have these items for the agenda. 1) review of entities proposal 2) OGF 22 - our session is Monday 2/25 at 4:15pm. Other agenda items? ...mikeb -- dfdl-wg mailing list dfdl-wg(a)ogf.org http://www.ogf.org/mailman/listinfo/dfdl-wg 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

1 0