- dfdl-wg - lists.ogf.org

AUTO: Sunil Dandamudi is out of the office (returning 04/01/2013)
by Sunil Dandamudi 28 Mar '13

28 Mar '13

I am out of the office until 04/01/2013. Note: This is an automated response to your message "dfdl-wg Digest, Vol 81, Issue 51" sent on 03/28/2013 10:00:02. This is the only notification you will receive while this person is away.

1 0

Multiple asserts on same object
by Steve Hanson 28 Mar '13

28 Mar '13

What's the expected behaviour if I place the following 2 asserts on the same object? <dfdl:assert>{fn:false()}</dfdl:assert> <dfdl:assert>{fn:false()}</dfdl:assert> Do both get evaluated, and the results 'stacked'? Or once the first fails do we not bother with the second? Spec is not clear. My motivation is to use multiple dfdl:asserts to get me out of nested points of uncertainty. I am seeing with IBM DFDL that the second is not evaluated. (The order of evaluation is implementation dependent, but as they are the same that makes no difference.) 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

1 0

Re: [DFDL-WG] whitespace in DFDL annotations: right now regex is xs:string, expression is xs:token
by Steve Hanson 27 Mar '13

27 Mar '13

Suman Looking at the XML schema-for-schemas, and doing a test in the XSD editor in eclipse, XSD enumeration facets are modelled as xs:NMTOKEN and not xs:string, like DFDL enums. XSD is perfectly happy to strip/collapse white space. I think therefore that we should be doing the same for DFDL enum properties. I don't see any harm in this - an enum is a contiguous sequence of non-whitespace characters anyway, so any leading/trailing whitespace is harmless. Looks like XSD pattern facet is modelled as xs:string, preserving white space. We should do the same for DFDL regex properties. 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: Suman Kalia <kalia(a)ca.ibm.com>, Cc: dfdl-wg(a)ogf.org, dfdl-wg-bounces(a)ogf.org, Mike Beckerle <mbeckerle.dfdl(a)gmail.com> Date: 19/03/2013 17:41 Subject: Re: [DFDL-WG] whitespace in DFDL annotations: right now regex is xs:string, expression is xs:token The type called DFDLExpressionOrPatternOrNothing only makes sense for use in one place - the element value of an assert or discriminator. 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: Suman Kalia <kalia(a)ca.ibm.com> To: Mike Beckerle <mbeckerle.dfdl(a)gmail.com>, Cc: dfdl-wg(a)ogf.org, dfdl-wg-bounces(a)ogf.org Date: 19/03/2013 17:29 Subject: Re: [DFDL-WG] whitespace in DFDL annotations: right now regex is xs:string, expression is xs:token Sent by: dfdl-wg-bounces(a)ogf.org Mike - I am not sure but my gut feeling is that it would start with the most restrictive one first. i.e If empty string ( assuming it has length facet 1) - would match Nothing , then xsd:token which is restricted form of xs:string. I think you are going to get string with white spaces collpsed ( xsd:token) if it not empty string. You can run few tests to see the behavior.. Suman Kalia IBM Canada Lab WMB Toolkit Architect and Development Lead Tel: 905-413-3923 T/L 313-3923 Email: kalia(a)ca.ibm.com For info on Message broker http://www.ibm.com/developerworks/websphere/zones/businessintegration/wmb.h… From: Mike Beckerle <mbeckerle.dfdl(a)gmail.com> To: dfdl-wg(a)ogf.org, Date: 03/19/2013 12:43 PM Subject: [DFDL-WG] whitespace in DFDL annotations: right now regex is xs:string, expression is xs:token Sent by: dfdl-wg-bounces(a)ogf.org This came up on the call. The schemas I have for DFDL annotations have DFDLRegularExpression as an xs:string, and DFDLExpression as an xs:token. I have no clue what a union of these types behaves like. But we have a union called DFDLExpressionOrPatternOrNothing which is a 3-way union of DFDLExpression, DFDLRegularExpression, and EmptyString (which is also derived from xs:string but has length facet of 0 as well. -- 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 -- 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

Are non-native attributes allowed on DFDL annotation elements?
by Mike Beckerle 27 Mar '13

27 Mar '13

In XML Schema you are allowed to throw in attributes even just as documentation i.e., <xs:element xmlns:rtfm="read:the:..manual." name="myElement" rtfm:yo="this element name is general lameness" .../> I.e, in the definition of xs:element there is this wildcard with standard lax validation for any non-native attributes. So, the question is do we want to also allow that on dfdl annotation elements, i.e, <dfdl:format byteOrder="bigEndian" rtfm:yo="it's LE Loser!" /> Given that you cannot nest  inside element syntax, these non-native attributes are the only convenient way to add commentary to the attributes of a XML document. Another perhaps more compelling reason to tolerate this is that I am sure in the next year all the DFDL implementation efforts are going to add some new experimental properties, and we will want to hang them on the same dfdl annotation elements. Schema inter-operation requires us each to tolerate the other's such experimental properties to the extent that they are not essential to the schema being usable at all. So if I have: <dfdl:element dafext:recursive="typesOnly" xmlns:dafext="some.daffodil.urn.for.extensions" ref="someOtherFormat" /> then we will want IBM DFDL and DFDL implementations generally, to perhaps warn that it was there and unrecognized, but not to just SDE on non-validation. Today, the XML Schemas for DFDL Annotations do not allow non-native attributes inside DFDL annotation elements, but the spec is silent on the subject. I was considering adding a couple of experimental properties (not right away, but maybe by year end), and I only realized today that they would break compatibility without a change here. Comments? -- Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | www.tresys.com

2 1

OGF DFDL WG Call Minutes 2013-03-26
by Steve Hanson 26 Mar '13

26 Mar '13

Please find minutes from the above call on Redmine at http://redmine.ogf.org/dmsf_files/13062?download= Errata document is now at v012 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

checkConstraints example?
by Garriss Jr., James P. 26 Mar '13

26 Mar '13

Can you please supply an example of using checkConstraints to valid an enumeration? There's not one in the spec, and none of the tutorials I have demo this. Suppose I have this DFDL: <xsd:element name="DayOfTheWeek"...> <xsd:simpleType> <xsd:restriction base="xsd:string"> <xsd:enumeration value="Mon" /> <xsd:enumeration value="Tue" /> <xsd:enumeration value="Wed" /> ... </xsd:restriction> </xsd:simpleType> </xsd:element> TIA

3 3

OGF DFDL WG Call Agenda 2013-03-26
by Steve Hanson 26 Mar '13

26 Mar '13

Please find agenda for call on Redmine at http://redmine.ogf.org/dmsf_files/13062?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

Lessons are AWOL
by Garriss Jr., James P. 25 Mar '13

25 Mar '13

All of the lessons on the OGF's DFDL page are AWOL: [cid:image001.png@01CE2954.370D6720] Viewed in FF on Win7.

2 3

whitespace in DFDL annotations: right now regex is xs:string, expression is xs:token
by Mike Beckerle 20 Mar '13

20 Mar '13

This came up on the call. The schemas I have for DFDL annotations have DFDLRegularExpression as an xs:string, and DFDLExpression as an xs:token. I have no clue what a union of these types behaves like. But we have a union called DFDLExpressionOrPatternOrNothing which is a 3-way union of DFDLExpression, DFDLRegularExpression, and EmptyString (which is also derived from xs:string but has length facet of 0 as well. -- Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | www.tresys.com

3 2

Re: [DFDL-WG] Action 206 - proposed timezone-from-dateTime function - update
by Steve Hanson 19 Mar '13

19 Mar '13

Also noticed that in section 23.5.2.4 we do not state what the type of the return value is from the various date/time functions. They are all xs:integer except for the 'seconds' functions which return xs:decimal as they include any fractional seconds. Suggest a sweep through all the other functions to check the return type is either stated or obvious. Regards Steve Hanson Architect, 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: 19/03/2013 08:55 Subject: Re: [DFDL-WG] Action 206 - proposed timezone-from-dateTime function Mike This function may be used anywhere, and not just in the context of an element of calendar type. You therefore can't use the value of dfdl:calendarTimeZone. You should just return empty string if there is no timezone component. We also need 3 variations of the function, like XPath 2.0: dfdl:timeZoneFromDateTime($arg as xs:dateTime?) as xs:string? dfdl:timeZoneFromDate($arg as xs:date?) as xs:string? dfdl:timeZoneFromTime($arg as xs:time?) as xs:string? Regards Steve Hanson Architect, 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: 18/03/2013 18:29 Subject: [DFDL-WG] Action 206 - proposed timezone-from-dateTime function Sent by: dfdl-wg-bounces(a)ogf.org I examined use of ISO durations, but that introduces a bunch of unnecessary complexity for implementors. I decided to propose instead use of an ISO 8601Time zone designator as an xs:string. Proposed: dfdl:timeZoneFromDateTime($arg as xs:dateTime?) as xs:string? Summary: Returns the timezone component of $arg if any. If $arg has a timezone component, then the result is a string in the format of an ISO Time zone designator. Interpreted as an offset from UTC, its value may range from +14:00 to -14:00 hours, both inclusive. UTC is represented as "Z". If the $arg has no timezone component, then the value of the dfdl:calendarTimeZone property expressed as an ISO 8601 Time zone designator is returned, or ""(empty string) is returned if the dfdl:calendarTimeZone property is ""(empty string). Examples dfdl:timeZoneFromDateTime(xs:dateTime("1999-05-31T13:20:00-05:00")) returns the xs:string value "-05:00". dfdl:timeZoneFromDateTime(xs:dateTime("2000-06-12T13:20:00Z")) returns the xs:string value "Z". dfdl:timeZoneFromDateTime(xs:dateTime("2004-08-27T00:00:00")) with dfdl:calendarTimeZone='America/New_York' returns the xs:string "-05:00". ---------- Forwarded message ---------- From: Mike Beckerle <mbeckerle.dfdl(a)gmail.com> Date: Tue, Jan 29, 2013 at 9:05 AM Subject: Re: clarification needed: datetime and time To: dfdl-wg(a)ogf.org I also believe this means we are missing this function: fn:timezone-from-dateTime($arg as xs:dateTime?) as xs:dayTimeDuration? However, we don't have this result type dayTimeDuration, so rather than add that type, which is a structured thing like: PnDTnHnMnS, we should say it matches the iso 8601 time zone suffix on an iso datetime. So "Z" or "-05:00" etc. Since it is not exactly the existing Xpath function, perhaps this function should not have this name or not be in the fn namespace. Come to think of it. I don't think we ever say exactly what the fn: prefix is bound to in DFDL. On Tue, Jan 29, 2013 at 8:55 AM, Mike Beckerle <mbeckerle.dfdl(a)gmail.com> wrote: In the below. Should xs:datetime have trailing timezone as well? Right now it has no tz component. Seems to me it should to match iso 8601 format which is what XSD uses. Also, I believe we now think ZZZ is not the right behavior, and seems to be deprecated in ICU. The right thing is ZZZZZ. calendarPatternKind Enum Valid values ‘explicit’, ‘implicit’ ‘explicit’ means the pattern is given by dfdl:calendarPattern, ‘implicit’ means the pattern is derived from the XML schema date/time type. Logical Type Default Pattern xs:date yyyy-MM-dd xs:dateTime yyyy-MM-dd'T'HH:mm:ss xs:time HH:mm:ssZZZ Annotation: dfdl:element, dfdl:simpleType -- Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | www.tresys.com -- Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | www.tresys.com -- 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

2 3