[dfdl-wg] alternate syntax for DFDL annotations

[Mike Beckerle]

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 at ggf.org [mailto:owner-dfdl-wg at ggf.org] On 
> Behalf Of Steve Hanson
> Sent: Wednesday, March 02, 2005 1:08 PM
> To: Myers, James D
> Cc: dfdl-wg at gridforum.org; owner-dfdl-wg at 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 at uk.ibm.com
> Phone (+44)/(0) 1962-815848
> 
> 
>                                                               
>              
>              "Myers, James D"                                 
>              
>              <jim.myers at pnl.go                                
>              
>              v>                                               
>           To 
>              Sent by:                  dfdl-wg at gridforum.org  
>              
>              owner-dfdl-wg at 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 at ggf.org [mailto:owner-dfdl-wg at ggf.org] 
> On Behalf 
> > Of Martin Westhead
> > Sent: Wednesday, March 02, 2005 12:16 PM
> > To: Mike Beckerle
> > Cc: dfdl-wg at 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
> > >
> >
> >
> 
> 
>