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@ca.ibm.com
From:
| Steve Hanson <smh@uk.ibm.com>
|
To:
| <mbeckerle.dfdl@gmail.com>
|
Cc:
| dfdl-wg@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@uk.ibm.com
Phone (+44)/(0) 1962-815848
----- Forwarded by Steve Hanson/UK/IBM on 20/05/2009 09:36 -----
"Mike Beckerle"
<mbeckerle.dfdl@gmail.com>
19/05/2009 22:44
Please respond to
<mbeckerle.dfdl@gmail.com> |
|
To
| Steve Hanson/UK/IBM@IBMGB,
<dfdl-wg@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 | OGF DFDL
WG Co-Chair | CTO | Oco, Inc.
Tel: 781-810-2125 | 100 Fifth Ave., 4th Floor, Waltham MA 02451
| mbeckerle.dfdl@gmail.com
"Mike Beckerle"
<mbeckerle.dfdl@gmail.com>
07/05/2009 01:45
Please respond to
<mbeckerle.dfdl@gmail.com> |
|
To
| Steve Hanson/UK/IBM@IBMGB,
<dfdl-wg@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.
Mike Beckerle | OGF DFDL
WG Co-Chair | CTO | Oco, Inc.
Tel: 781-810-2125 | 100 Fifth Ave., 4th Floor, Waltham MA 02451
| mbeckerle.dfdl@gmail.com
From: dfdl-wg-bounces@ogf.org [mailto:dfdl-wg-bounces@ogf.org]
On Behalf Of Steve Hanson
Sent: Wednesday, May 06, 2009 1:22 PM
To: dfdl-wg@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@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
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@ogf.org
http://www.ogf.org/mailman/listinfo/dfdl-wg