Sorry for missing our call today, and thanks to everyone for the rapid feedback on the non-native attributes approach. I think there's a consensus here that non-native attributes are going too far, and that if we can just make the appinfo annotations a bit more dense we'll be happy. So , for now, we're not going to do non-native attributes in our DFDL prototype, I'll make a note about the possiblility in an appendix of the doc though. None of the tools I have will validate them, and that's a big drawback. Right now, our prototype handles small examples with annotations that look like this: <xs:element name="foo" type="xs:int"> <xs:annotation> <xs:appinfo source="http://dataformat.org/"> <dfdl:dataFormat byteOrder="bigEndian" charset="UTF-8"> <!-- some properties are attributes --> <dfdl:separator>,</dfdl:separator> <!-- other properties are elements --> </dfdl:dataFormat> </xs:appinfo> </xs:annotation> </xs:element> Note that if you use appinfo annotations then you don't need namespace qualification on the attribute names. We also allow for "extension" declarations in that the dfdl:dataFormat element is the head of a XSD substitution group, So you can also define an extension like ascl:binaryIntegerFormat below: <xs:element name="foo" type="xs:int"> <xs:annotation> <xs:appinfo source="http://dataformat.org/"> <ascl:binaryIntegerFormat byteOrder="bigEndian"/> </xs:appinfo> </xs:annotation> </xs:element> The ascl:binaryIntegerFormat is a narrowing. It doesn't allow any properties to be specified that don't make sense for a binary integer. It's in a different namespace to illustrate that these could be defined by a DFDL user in their DFDL schema, not just by the dfdl implementation itself. The basic dfdl:dataFormat element allows any and all representation properties. Whether we supply standard library elements which are narrowings of it, or let those be defined by end-users is something we can discuss. This all comes for free by just using XSD properly. It adds almost nothing to the implementation. ...mikeb
-----Original Message----- From: owner-dfdl-wg@ggf.org [mailto:owner-dfdl-wg@ggf.org] On Behalf Of Steve Hanson Sent: Wednesday, March 02, 2005 1:08 PM To: Myers, James D Cc: dfdl-wg@gridforum.org; owner-dfdl-wg@ggf.org Subject: RE: [dfdl-wg] alternate syntax for DFDL annotations
I can't say I am over keen on this, because - you will end up with odd rules where some properties can be attributes and some can't, which will confuse users. - you have to invent errors and/or overide behaviour when you get a clash between attribute and annotation - (minor) it makes the job of any software that instantiates a dfdl memory model harder
If we do adopt this then #2 is preferable.
Regards, Steve
Steve Hanson WebSphere Business Integration Brokers, IBM Hursley, England Internet: smh@uk.ibm.com Phone (+44)/(0) 1962-815848
"Myers, James D"
<jim.myers@pnl.go
v> To Sent by: dfdl-wg@gridforum.org
owner-dfdl-wg@ggf cc .org
Subject RE: [dfdl-wg] alternate syntax for 02/03/2005 17:35 DFDL annotations
I agree - I think I like #2. I know at one point in the past we had complaints when we tried to use attributes with namespaces - it may just have been that parsers weren't dealing with them correctly early on. Whatever it was, option 2 would provide a work around as well as helping us keep a single 'canonical' form for DFDL.
Jim
-----Original Message----- From: owner-dfdl-wg@ggf.org [mailto:owner-dfdl-wg@ggf.org] On Behalf Of Martin Westhead Sent: Wednesday, March 02, 2005 12:16 PM To: Mike Beckerle Cc: dfdl-wg@gridforum.org Subject: Re: [dfdl-wg] alternate syntax for DFDL annotations
Hi Mike,
This is interesting I wasn't aware you could do this. My concern would be if it turned out the schema tools couldn't handle it but I tried XML Spy which seems to just ignore the extra annotations.
So I'd be happy to use them. As you point out we will need both these and annotations so we are left with a choice. Either we:
1. Specify some (most) dfdl additions in this non-native attribute form and use annotations when required or
2. We specify everything as annotations but allow this form as a systematic short hand.
I think I prefer (2). The sort of thing I have in mind is making the annotation syntax look like:
<xs:element name="foo" type="xs:string"> <annotation> <appinfo> <dfdl:attributes dfdl:repType="text" dfdl:charset="UTF-8" dfdl:repLength="10"/> </appinfo> <annotation </xs:element>
And then this be directly equivalent (and trivially transformed into/from) what you had before:
<xs:element name="foo" type="xs:string" dfdl:repType="text" dfdl:charset="UTF-8" dfdl:repLength="10"/>
I'm not sure if it matters that much but it seems like it might be neater if everything could be represented in the same form.
Also there may be times when you would like to use the annotation form because you have a bock of stuff that could be reused multiple times. Once your annotations have become attributes in the main schema they are more intimately tied to it.
Cheers,
Martin
Mike Beckerle wrote:
Up til now we've considered DFDL annotations only as inside the appinfo context. However, we should consider whether we should use non-native attributes as well or
as an alternative: E.g., simple DFDL rep properties could also be expressed like this:
<xs:element name="foo"
type="xs:string"
dfdl:repType="text"
dfdl:charset="UTF-8"
dfdl:repLength="10"/>
This has the advantages of compactness, and is a fully supported way of extending XML Schema. That is, using non-native attributes is a supported extension idiom. This won't handle things that really need the syntactic support of element structure to express their complexity, e.g., things like specifying text delimiters with quoting and escape-sequence specifications. For those we'll still need to open an appinfo annotation up. However, for basic things like byteOrder and such it is far more attractive syntactically to use non-native attributes than appinfo annotations.
Comments?
...mikeb