- dfdl-wg - lists.ogf.org

DFDL ICU Challenges for Implementation
by Mike Beckerle 14 Aug '13

14 Aug '13

There are a couple of features in DFDL that ICU doesn't support, yet where all or nearly all the related functionality is supported by ICU. Perhaps these aspects of the spec can be revisited? 1) List of Decimal Separators The textStandardDecimalSeparator property is a list of characters. However, ICU only supports a single character. I see lots of potential for error here, confusing diagnostics, etc. It is not consistent with textStandardGrouping separator, which allows only a single character. Is there a use case where we know we need more than one decimal separator? The only thing I can think of is a blend of say classic European-style decimal numbers like "1 234 567,89" and USA style " 1,234,567.89", but ICU won't deal with different grouping separators either. In any case if there are multiple decimal and grouping separators we really don't have these properties right in DFDL. We should require them to be specified not as two separate lists, but as a list of pairs, because grouping separators match up with specific decimal separator values in a format. 2) Case Insensitivity Some properties that we use to configure ICU are affected by ignoreCase="yes", but ICU does not support case insensitivity. The properties are: textStandardExponentRepCharacter textStandardInfinityRep textStandardNaNRep I can certainly imagine a need for case insensitivity here, and even for multiple values for these (though we allow only one for Infinity and NaN). For the infinity and nan reps that isn't so problematic as one can easily do a pre-check before calling ICU, but for the exponent rep, that is needed down in the detailed number format parsing. I can see no certain algorithm other than creating separate number format parsers for each exponent rep character in provided case, and opposite case, and then using them one by one until a successful parse. Is this ok or do we consider this a mistake? 3) We are not very consistent in these properties. We allow multiple textStandardZeroRep values, but only a single textStandardInfinityRep, and only a single textStandardNaNRep. We allow multiple textStandardExponentRepCharacter, and multiple textStandardDecimalSeparator, but only a single textStandardGroupingSeparator. This kind of inconsistency is always problematic for users. Comments?

1 0

Extra restrictions needed for dfdl:floating 'yes' ?
by Steve Hanson 14 Aug '13

14 Aug '13

Section 14.4 of the spec says: "An ordered sequence of n element children with either n or n-1 of those children with dfdl:floating='yes' is equivalent to an unordered sequence with the same n element children with dfdl:floating='no'." Does this mean that the extra restrictions we recently added for unordered sequences must also apply to floating elements? If so these would manifest themselves as: It is a schema definition error if an element with dfdl:floating 'yes' is an optional element or an array element and its dfdl:occursCountKind property is not ‘parsed’. It is a schema definition error if two or more elements with dfdl:floating 'yes' in the same group have the same name and the same namespace. Regards Steve Hanson Architect, IBM Data Format Description Language (DFDL) Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848 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

3 3

clarification needed: validation errors
by Mike Beckerle 14 Aug '13

14 Aug '13

Jessie Chab (tresys) said: ...... The wording of "Validation errors cannot be suppressed by points of uncertainty" was tripping me up. Though I understand what points of uncertainty are, it is unclear exactly what this is saying. When viewed as a continuation of the requirement "validation errors are ignored when resolving points of uncertainty" it seems to make a little more sense. Overall, the requirements together are saying (i believe), Validation errors are not taken into account when resolving points of uncertainty, but they are still going to occur and be present to the user upon a successful parse. I think this could be said a little more clearly in the spec.

2 1

Re: [DFDL-WG] clarification needed for scan and scannable
by Steve Hanson 14 Aug '13

14 Aug '13

Action 217 raised to decide new terminology for the regex scanning encoding requirement. Regards Steve Hanson Architect, IBM Data Format Description Language (DFDL) Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848 From: Mike Beckerle <mbeckerle.dfdl(a)gmail.com> To: Tim Kimber/UK/IBM@IBMGB, Cc: Steve Hanson/UK/IBM@IBMGB Date: 30/07/2013 01:01 Subject: Re: clarification needed for scan and scannable I reviewed the spec. I have to reverse my prior statement. What you describe is definitely currently allowed by the spec. The 'scannable' restriction is reserved for lengthKind='pattern'. In my view this is a terrible idea, but it is where it is. I.e., that the lengthKind 'delimited' doesn't require 'scannable' characteristic throughout everything that is contained within it. It will not allow us to really assist users in identifying what are very likely to be mistakes in their schemas, because what we call 'delimited' is much too permissive. I am not going to argue to change this at the current time. This is just due to the need to converge on the standard. My preference would be that lengthKind 'delimited' requires scannability (as uniform text), and that some new keyword be used to mean the current algorithm as specified. I do suggest that we rename the characteristic scannability to scannable-as-text, in order to make it clearer what the requirement is, and clarify that this is a requirement on the schema component. I suspect that lengthKind='delimited' will perhaps someday (DFDL v2.0?) be deprecated and/or augmented by other keywords that are more specific such as "delimitedText" which means scanning for delimiters over only text in one encoding (the 'scannable' restriction), and other keywords like "delimitedBinary" or "delimitedMixed" meaning formats which admit the more powerful and complex things. My argument is simple: if people have something like delimiters in distinct encodings appearing in their schema, it is most-likely due to a human error (they missed one place when they were editing the encoding property), rather than something as obscure as this delimiters-in-a-different-encoding being a real characteristic of the data. An SDE here will help them find this error. Furthermore, if you truly want a string to be terminated by either an ebcdic comma (6B) or an ascii linefeed (0A), then you have a few alternatives before you have to go to the now optional feature of 'rawbyte', and which are consistent with scannability. First, use encoding ascii, and specify terminators of %LF;, and 'k' (or %#x6B; since 'k' is 6B ascii), in which case the string is assumed to contain only ascii code units. In that case, if ebcdic 'a' (x81 - illegal in ascii) is encountered in the data, you will either get an error or a unicode replacement character depending on encodingErrorPolicy. If you know your data will only ascii-legal code units, then this is a good solution. I would note that your example (previously in the thread) did not specify an encoding for the innermost string elements. Did you intend for those to be ebcdic or ascii? Alternatively you can specify encoding ebcdic-cp-us, specify terminator of comma (codepoint x6B) and %#x0A; which is the RPT control code in ebcdic but not an illegal character. In that case the string can contain any legal ebcdic code point. However, if code unit x70 is encountered (corresponds to an ascii 'p', but unmapped in ebcdic-cp-us), you will either get an error, or a unicode replacement character depending on encodingErrorPolicy. If you know your data will contain only legal ebcdic code units, then this is a good solution. Finally, you can specify encoding iso-8859-1, and terminators %#x6B; (or 'k' which is 6B in iso-8859-1) and %#x0A; (linefeed in iso-8859-1). Then any code units at all will be legal as all bytes have corresponding character codepoints in iso-8859-1. If you have no idea what the data is, but just want some sort of string out of it, and know only that the terminators are these bytes, then this is a good solution. If your data contains, for example, packed-decimal numbers, then this is the only way to safely scan past it as a string, because both ebcdic and ascii have unmapped code points from the code units that could appear in packed-decimal number bytes. All the above are consistent with implementations that attempt to convert data from code-units (bytes) to Unicode codepoints using a character set decoder, and then apply any scanning/searching only in the Unicode realm, and work in one pass over the data. I currently think that to implement both rawbytes and encodingErrorPolicy it will require two passes over the data. I expect this overhead to be negligible, so I'm not worried about it really. ...mike On Mon, Jul 29, 2013 at 7:18 AM, Tim Kimber <KIMBERT(a)uk.ibm.com> wrote: Hi Mike, Good - that was almost exactly the reply that I was expecting. I now understand exactly where you are coming from, and how we arrived at this position. First, a few statements that I think are true. I want to establish some basic ground rules before we decide how to go forward: a) it is desirable for DFDL ( more accurately, a valid subset of DFDL ) to be implementable using well known parsing techniques. I think that pretty much means regular expressions and BNF-style grammars. That implies that it might be possible to implement a DFDL parser using one of the well-known parser-generator technologies like Yacc/Bison/JavaCC/Antlr. I'm not claiming that it *is* possible, but I think it would be a good thing if it was. b) It is technically feasible to implement a DFDL parser that can handle the mixed-encoding example using regex technology. However, it would not be a very efficient implementation because the scanner would have to scan the data once per encoding, and it would have to do that for every character after the end of field1. c) It is possible to produce an efficient scanner that handles mixed encodings. Such a scanner cannot use regex technology for scanning - in fact, I think the only efficient implementation is to convert all terminating markup into byte sequences and then perform all scanning in the byte domain. This is what the IBM implementation does. The scenario in my example is not entirely far-fetched - it is conceivable that the encoding might change mid-way through a document, and I think Steve came up with a real-world format that required this ( I have a hazy memory of discussing this a couple of years ago ). The requirement for the raw byte entity is not for this case - it is for the case where the delimiters are genuinely not characters ( e.g. a UTF-16 data stream terminated by a single null byte ). However, it is not easy to come up with realistic examples where the raw byte entity could not be translated into a character before the processor uses it. I think that's where some of the confusion has arisen. We have already agreed to make the raw byte entity an optional feature. We should consider disallowing mixed encodings when lengthKind is delimited. If we cannot do that then I agree with Mike that the descriptions and definitions in the spec need to be made a bit clearer. regards, Tim Kimber, DFDL Team, Hursley, UK Internet: kimbert(a)uk.ibm.com Tel. 01962-816742 Internal tel. 37246742 From: Mike Beckerle <mbeckerle.dfdl(a)gmail.com> To: Tim Kimber/UK/IBM@IBMGB, Cc: Steve Hanson/UK/IBM@IBMGB Date: 26/07/2013 22:49 Subject: Re: clarification needed for scan and scannable Clearly we have to rework the description and definitions because my understanding of the current spec would say your schema is not valid because it is not scannable. Everything in the scope of the enclosing element which is delimited must be scannable and that means uniform encoding. It is exactly to rule out this mixed encoding ambiguity that we have the restriction. I have no idea how to implement delimiters without this restriction. I think the case you have here is what raw bytes are for. Though I am no longer clear on how to implement rawbytes either. On Jul 25, 2013 6:40 PM, "Tim Kimber" <KIMBERT(a)uk.ibm.com> wrote: Suppose I have this DFDL XSD: <xs:element name="documentRoot" dfdl:encoding="US-ASCII" dfdl:lengthKind= "delimited" dfdl:terminator="]]]"> <xs:complexType> <xs:sequence> <xs:element name="delimitedRecord" maxOccurs="unbounded" dfdl:encoding="US-ASCII" dfdl:lengthKind="delimited" dfdl:terminator="%LF;"> <xs:complexType> <xs:sequence dfdl:separator="," dfdl:separatorSuppressionPolicy= "suppressedAtEndLax" dfdl:encoding="EBCDIC-US"> <xs:element name="field1" type="xs:string" dfdl:lengthKind= "delimited"> <xs:element name="field2" type="xs:string" dfdl:lengthKind= "delimited" minOccurs="0"> <xs:element name="field3" type="xs:string" dfdl:lengthKind= "delimited" minOccurs="0"> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> ...which will parse some data like this: field1Value,field2Value,field3Value field1Value, field1Value,field2Value]]] ...except that the commas that delimit the fields are in EBCDIC and the linefeeds that delimit the records are in ASCII . I have purposely constructed this example with separatorSuppressionPolicy set to 'suppressedAtEndLax'. This means that field1 and field2 could both be terminated by either of a) an EBCDIC comma or b) an ASCII line feed This is a very artificial example, but it is valid DFDL and should not produce schema definition error. If we use the term 'scan' when discussing lengthKind='delimited' then we need to be careful how to define the term 'scannable' - otherwise we might appear to prohibit things that are actually valid. I think this is the same point that Steve was making. Most implementations will do the same as Daffodil and will use a regex engine to implement all types of scanning, including lengthKind='delimited'. It's the most natural solution, and it can be made to work as long as a) the implementation takes extra care if/when the encoding changes within a component and b) the implementation either does not support the raw byte entity, or only supports it when it can be translated to a valid character in the component's encoding. There is huge scope for confusion in this area - most readers of the DFDL specification will assume that delimited scanning can be implemented using regex technology + EBNF grammar. It may be possible ( I'm not claiming that it is btw ), but the grammar would be decidedly non-trivial. so the DFDL specification should take extra care to be unambiguous when discussing how to scan for terminating markup. regards, Tim Kimber, DFDL Team, Hursley, UK Internet: kimbert(a)uk.ibm.com Tel. 01962-816742 Internal tel. 37246742 From: Mike Beckerle <mbeckerle.dfdl(a)gmail.com> To: Steve Hanson/UK/IBM@IBMGB, Cc: Tim Kimber/UK/IBM@IBMGB Date: 25/07/2013 19:04 Subject: clarification needed for scan and scannable If a user has read the Glossary and noted the definition of 'scannable' then when he sees the terms 'scanning' and 'scanned' in 12.3.2 he may think that this implies data being read by lengthKind must be 'scannable', and it is not so. That's how I read the spec, hence my original comment. I find it confusing to define 'scan' and then not to define 'scannable' as 'able to be scanned'. Ok, so i am rethinking how we express what we mean by scan. scan - verb. The action of attempting to find something in characters. Implies decoding the characters from code units to character codes. A scan can succeed on real data, or fail (no match, not found), but both are normal behaviors for a scan. However, this is predicated on the data at least being meaningfully decoded into characters of a single character set encoding. This is because our regex technology isn't expected to be able to shift encodings mid match/scan, nor is it expected to be able to jump over/around things that aren't textual so as not to misinterpret them as code units of characters. So saying a schema component is scannable - means the schema expresses the assumption that the data is expected to be all textual/characters in a uniform encoding so that it is meaningful to talk about scanning it with the kind of regex technology we have available today. That is, there's no need to consider encoding changes mid match, nor what data to jump over/around. This is the sense of "scan" -able that we use the term to mean. Our expectation as expressed in the schema, is that so long as the data decodes without error the scan will either succeed or fail normally. Actual data is scannable if it meets this expectation. Contrast with what happens for an assert with testKind='pattern'. In that case we scan, but DFDL processors aren't required to provide any guarantee that the data is scannable, which means the designer of that regex pattern must really know the data, and know what they are doing, as to avoid the issues of decode-errors. Why do we do this? Because we don't want to have to refactor a complex type element into two sequences one of which is the stuff at the front that an assert with test pattern examines, and the other of which is the stuff after that. In some situations it may be very awkward or impossible to separate out the part at the front that we need to scrutinize. Instead we just allow you to put the assert at the beginning, and it is up to the regex designer to know that the first few fields it looks at the data for, are scannable (in the sense of the expectation of them being text), or if not scannable in terms of that expectation from the schema, then at least that the actual contents of them will not have data that interpreted as character code points, will cause decode errors. In other words the writer of a test pattern has to know that either the data is scannable (schema says so), or that the actual data will actually be scan-able, in that decode errors won't occur if it is decoded. This also provides a backdoor by which one can use regex technology to match against binary data. But then you really have to understand the data so as to understand exactly what code units will be found in it, so one can understand what the regex technology will do. One can even play games with encoding="iso-8859-1", where no decoding errors are possible, so as to guarantee no decode errors when scanning binary data that really shouldn't be thought of as text. The part of the data that a test pattern of an assert actually looks at needs to be scannable by schema expectation, or scannable in actual data contents. If you write a test pattern, expecting to match things in what will turn out to be the first and second elements of a complex type, but the encoding is different for the second element, then your test pattern isn't going to work (you may get false matches, false non-matches, or may get decode errors) because the assumption that the data is scannable for that first and second element, is violated. Summary: can we just say scan - verb scannable - a schema component is scannable if ... current definition. Data is scannable with respect to a specific character set encoding if, when it is interpreted as a sequence of code units, they always decode without error. There are two ways to make "any data" scannable for certain. One - set encodingErrorPolicy to 'replace'. Now all data will decode without error because you get substitution characters insteead. Two - change encoding to iso-8859-1 or other supported encoding where every byte is a legal code unit. If you are in neither situation One or Two above, then you have to say the data is scannable, but with respect to a specific encoding. So saying the data is scannable as ASCII means that it will not contain any bytes that interpreted as ASCII code units will be illegal. For this example, that means all the bytes have values from 0 to 127 (high bit not set). If you know that will be true of your data, then even if it is binary data you can say it is scannable as ASCII. The representation of Packed Decimal numbers are not scannable as ascii, for example, because any high-nibble digit 8 or greater will cause the byte containing it to have a value 128 or higher, for which there is no corresponding ascii code unit. Packed Decimal numbers are also not scannable as UTF-8, because many packed decimal bytes will not be legal utf-8 code unit values, nor will they be in the ordered arrangements UTF-8 requires. 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 -- Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | www.tresys.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

1 0

Re: [DFDL-WG] Spec bug: WSP* should not be allowed for textStandardZeroRep
by Steve Hanson 14 Aug '13

14 Aug '13

Agreed to take an errata to disallow %WSP*; on its own in places where it is currently allowed but %ES; is not allowed. Regards Steve Hanson Architect, IBM Data Format Description Language (DFDL) Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848 From: Steve Hanson/UK/IBM To: Mike Beckerle <mbeckerle.dfdl(a)gmail.com>, Cc: dfdl-wg(a)ogf.org, dfdl-wg-bounces(a)ogf.org Date: 12/08/2013 15:53 Subject: Re: [DFDL-WG] Spec bug: WSP* should not be allowed for textStandardZeroRep Mike %WSP*; is useful tacked onto the end of string literal properties that don't allow %ES; so I think the correct restriction is that if a property does not allow %ES; it should not allow %WSP*; on its own. Regards Steve Hanson Architect, IBM Data Format Description Language (DFDL) Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848 From: Mike Beckerle <mbeckerle.dfdl(a)gmail.com> To: dfdl-wg(a)ogf.org, Date: 10/08/2013 17:02 Subject: [DFDL-WG] Spec bug: WSP* should not be allowed for textStandardZeroRep Sent by: dfdl-wg-bounces(a)ogf.org We don't allow %ES; for textStandardZeroRep. But we do allow character class entities like %NL; %WSP; %WSP+; and... problematic: %WSP*; I claim if you don't allow %ES; you should not allow %WSP*; because it matches zero-or-more, allowing an empty-string to match in principle. Leaving off WSP* only eliminates the zero-characters option, as WSP+ is available. There are probably other places in the spec that have this same issue. Basically, anyplace that %ES is disallowed but the other character class entities are allowed. -- Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | www.tresys.com -- dfdl-wg mailing list dfdl-wg(a)ogf.org https://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 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

OGF DFDL WG Call Minutes 2013-08-13
by Steve Hanson 14 Aug '13

14 Aug '13

Please find minutes from the above two calls at http://redmine.ogf.org/dmsf_files/13104?download=. Errata document is now at v013 here: http://redmine.ogf.org/dmsf_files/8104?download= Action 140 errata addendum at v001 here: http://redmine.ogf.org/dmsf_files/13017?download= Regards Steve Hanson Architect, IBM DFDL, Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848

1 0

Fw: Clarification needed on changes to Erratum 2.121 in Errata doc draft r14.0
by Steve Hanson 13 Aug '13

13 Aug '13

Agreed that the SMH responses to Mike's comments would be adopted. Regards Steve Hanson Architect, IBM Data Format Description Language (DFDL) Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848 ----- Forwarded by Steve Hanson/UK/IBM on 13/08/2013 17:14 ----- From: Steve Hanson/UK/IBM To: Mike Beckerle <mbeckerle.dfdl(a)gmail.com>, Cc: Tim Kimber/UK/IBM@IBMGB Date: 12/08/2013 15:48 Subject: Re: Clarification needed on changes to Erratum 2.121 in Errata doc draft r14.0 Mike - clarifications below. Regards Steve Hanson Architect, IBM Data Format Description Language (DFDL) Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848 From: Mike Beckerle <mbeckerle.dfdl(a)gmail.com> To: Tim Kimber/UK/IBM@IBMGB, Steve Hanson/UK/IBM@IBMGB, Date: 10/08/2013 15:26 Subject: Clarification needed on changes to Erratum 2.121 in Errata doc draft r14.0 There have been changes in r14 to erratum 2.121. Some things are ambiguous. Clarifications needed are noted below. • Add support for new ‘x’ and ‘X’ symbols. Just single 'x' and 'X', or all variations, i.e., x, xx, xxx, xxxx, and xxxxx, and X, XX, XXX, XXXX, and XXXXX ? SMH: Intention was all variations of 'x' and 'X'. • Add support for new ‘o’ and ‘O’ symbols Don't see 'o' only 'O' on the reference web page given. Is this correct? SMH: My mistake. Should be all variations of 'O'. • Adopt revised semantic for the ‘V’ symbol when used as ‘V’ and ‘VVVV’ To confirm, we don't allow 'VV' or 'VVV'. Only single V, and VVVV. SMH: We may as well allow all variations of 'V'. -- Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | www.tresys.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 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

OGF DFDL WG Call Agenda 2013-08-13 - 1 hour later from this week onwards
by Steve Hanson 13 Aug '13

13 Aug '13

Please find agenda for call on Redmine at http://redmine.ogf.org/dmsf_files/13104?download= Regards Steve Hanson Architect, IBM Data Format Description Language (DFDL) Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848

1 0

Rescheduled: OGF DFDL WG Call (13 Aug 16:00 GDT in DE3S09)
by Steve Hanson 13 Aug '13

13 Aug '13

OGF DFDL WG weekly call dial-in details. Passcode for Participants: 5381214 Canada Toll-Free 888-426-6840 China Toll-Free 10-800-711-1071 CHINA NETCOM GROUP USERS China Toll-Free 10-800-110-0996 CHINA TELECOM SOUTH USERS France Toll-Free 0800-94-0558 Germany Toll-Free 0800-000-1018 India Toll-Free 000-800-100-1176 Ireland Toll-Free 1-800-943-427 Israel Toll-Free 1-809-417-783 United Kingdom Caller Paid 0-20-30596451 United Kingdom Toll-Free 0800-368-0638 USA Caller Paid 215-861-6239 USA Toll-Free 888-426-6840 Other international numbers available - e-mail smh(a)uk.ibm.com. OGF DFDL Home: http://www.ogf.org/dfdl Redmine DFDL: http://redmine.ogf.org/projects/dfdl-wg Moving to 1 hour later from 13th August

1 0

OGF DFDL WG Call Agenda 2013-08-13 - PLEASE READ NOW
by Steve Hanson 12 Aug '13

12 Aug '13

Please find agenda for call on Redmine at http://redmine.ogf.org/dmsf_files/13104?download= IBM are requesting a change of time for future calls, so it starts one hour later. Please can you reply if that is acceptable, and whether your answer applies to this week's call. Regards Steve Hanson Architect, IBM Data Format Description Language (DFDL) Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848

3 2