[DFDL-WG] DFDL: Applying DFDL annotations to elements

Wed May 20 08:02:19 CDT 2009

I tend to agree top level has to be element.. I recall we had the option 
of putting a format to use at schema level which would apply to all top 
level elements defined in the schema..

Suman Kalia
IBM Toronto Lab
WMB Toolkit Architect and Development Lead
WebSphere Business Integration Application Connectivity Tools 

http://www.ibm.com/developerworks/websphere/zones/businessintegration/wmb.html

Tel : 905-413-3923  T/L  969-3923
Fax : 905-413-4850 T/L  969-4850
Internet ID : kalia at ca.ibm.com

From:
Steve Hanson <smh at uk.ibm.com>
To:
<mbeckerle.dfdl at gmail.com>
Cc:
dfdl-wg at ogf.org
Date:
05/20/2009 08:36 AM
Subject:
Re: [DFDL-WG] DFDL: Applying DFDL annotations to elements

Mike - I've combined both your replies. 

But if you specify a type instead of an element, how do you define a 
lengthKind for the structure (sequence can't carry it any more) and what 
name do you use in the infoset?  I think top-level needs to be an element. 

Regards

Steve Hanson
Programming Model Architect
WebSphere Message Brokers
Hursley, UK
Internet: smh at uk.ibm.com
Phone (+44)/(0) 1962-815848 
----- Forwarded by Steve Hanson/UK/IBM on 20/05/2009 09:36 ----- 
"Mike Beckerle" <mbeckerle.dfdl at gmail.com> 
19/05/2009 22:44 

Please respond to
<mbeckerle.dfdl at gmail.com>

To
Steve Hanson/UK/IBM at IBMGB, <dfdl-wg at ogf.org> 
cc

Subject
RE: [DFDL-WG] DFDL: Applying DFDL annotations to elements

I like the idea of specifying a type for the file, instead of a 
distinguished top-level  element. 

"Mike Beckerle" <mbeckerle.dfdl at gmail.com> 
07/05/2009 01:45 

Please respond to
<mbeckerle.dfdl at gmail.com>

To
Steve Hanson/UK/IBM at IBMGB, <dfdl-wg at ogf.org> 
cc

Subject
RE: [DFDL-WG] DFDL: Applying DFDL annotations to elements

Hmmm. This is the dilemma of is an object different from an instance of 
its type. 

E.g., if a complex type has a terminator is that the terminator on the 
element that has that type? 

We could define the syntax you used as redundant: 

<element name="foo" dfdl:ref="a"> 
   <complexType dfdl:ref="a">  // means same thing as if also hoisted onto 
the element having this type. 
                                             // i.e., ref applies to scope 
of complexType AND to elements having this type. 
     ... 

It is true we do not allow dfdl:ref on the xs:schema element. This is for 
very important reasons of keeping us out of the whole lexical vs. 
non-lexical scoping morass. Let's not go there. 

From: dfdl-wg-bounces at ogf.org [mailto:dfdl-wg-bounces at ogf.org] On Behalf 
Of Steve Hanson
Sent: Wednesday, May 06, 2009 1:22 PM
To: dfdl-wg at ogf.org
Subject: [DFDL-WG] DFDL: Applying DFDL annotations to elements

To apply DFDL annotations to a top-level element in a DFDL xsd, most 
modellers would use the dfdl:element dfdl:ref property to refer to a named 
dfdl:defineFormat block that set up the necessary defaults for all the 
DFDL properties. To avoid having to re-state the dfdl:ref property on 
every object that comprises the format, most modellers would also use the 
dfdl:complexType dfdl:ref property to scope the same dfdl:defineFormat 
block.  The xsd would look like below. 

<xs:schema ...> 
 <xs:annotation><xs:appinfo source=”http://www.ogf.org/dfdl/”> 
     <dfdl:defineFormat name=”textFormat1"> 
       <dfdl:format encoding="utf-8" separator="\n" representation=”text” 
lengthKind="delimited" /> 
     </dfdl:defineFormat> 
 </xs:appinfo></xs:annotation> 
 ... 
 <xs:element name="textDoc" dfdl:ref="textFormat1" 
dfdl:lengthKind="implicit"> 
          <xs:complexType dfdl:ref="textFormat1"> 
              <xs:sequence> 
           ... 
              </xs:sequence> 
          </xs:complexType> 
 </xs:element> 
 ... 
</xs:schema> 

It's not possible to put DFDL defaults in scope for the whole format with 
a single dfdl:ref property. I think this is a side-effect of removing the 
dfdl:appliesTo property. 

If this is thought to be an issue, there are a couple of options: 

One is to say that a complex type can be the top-level object. This is the 
case with several XML based systems. It works with XML because the XML 
instance document provides the name of top level element in the infoset 
via its tag. This is not the case with DFDL where the name is commonly not 
carried with the format. So we'd have no name for the infoset. 

Another is to provide a new property on dfdl:defineFormat, which says this 
dfdl:defineFormat is the default for all top-level objects in the xsd. Any 
top-level object that remained silent as to its dfdl:ref would get the 
default applied. I'm not sure whether this makes the model too opaque 
though. No more so than the existing scoping rules, I suspect. 

Any other opinions or suggestions welcome. 

Regards

Steve Hanson
Programming Model Architect
WebSphere Message Brokers
Hursley, UK
Internet: smh at uk.ibm.com
Phone (+44)/(0) 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 

--
  dfdl-wg mailing list
  dfdl-wg at ogf.org
  http://www.ogf.org/mailman/listinfo/dfdl-wg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/dfdl-wg/attachments/20090520/1e222f94/attachment-0001.html 