Alan
I've re-read the spec and you are quite right.
That just leaves b), a use case for which personally I have no need.
I therefore have no objection to the removal of multiple non-selector
annotations.
Regards
Steve Hanson
Programming Model Architect, WebSphere Message Brokers,
OGF DFDL WG Co-Chair,
Hursley, UK,
Internet: smh@uk.ibm.com,
Phone (+44)/(0) 1962-815848
From:
Alan Powell/UK/IBM
To:
Steve Hanson/UK/IBM@IBMGB
Cc:
dfdl-wg@ogf.org, dfdl-wg-bounces@ogf.org
Date:
23/10/2009 08:59
Subject:
Re: [DFDL-WG] Fw: DFDL Scoping v6
Steve
The semantics of selectors are the you select the dfd:format block with
the matching selector OR the dfdl:format block with no selector at an
annotation point. I don't think that case 1a was supported anyway.
Alan Powell
MP 211, IBM UK Labs, Hursley, Winchester, SO21 2JN, England
Notes Id: Alan Powell/UK/IBM email: alan_powell@uk.ibm.com
Tel: +44 (0)1962 815073 Fax: +44 (0)1962 816898
From:
Steve Hanson/UK/IBM@IBMGB
To:
dfdl-wg@ogf.org
Date:
22/10/2009 18:41
Subject:
[DFDL-WG] Fw: DFDL Scoping v6
A couple of things about the new scoping rules:
1) As Alan said in the minutes, there was one thing we didn't discuss on
the call, namely a proposal that multiple DFDL format annotations on the
same XSDL component be disallowed. This simplifies things, as we currently
have rules that govern how properties on multiple annotations combine.
Whilst agreeing that this a simplification is desirable, if I recall
correctly, there were a couple of motivating use cases, which we should
bear in mind when deciding this:
a) I am using selectors to model two different format variations, and some
properties are common to both. I code the common properties in one
dfdl:selector-free annotation, and the ones that differ in two annotations
that have a dfdl:selector.
b) I am simulating multiple inheritance by using two annotations each with
a different dfdl:ref.
2) One other thing was discussed on the call. Relates to rule 3 below.
When a component's set of 'explicit' properties are combined with the
working set of 'explicit' properties, it is a schema definition error if
same property appears in each set. It was questioned whether it should be
an error if the properties have the same value. We agreed to leave the
rule as-is, but revisit it if it proved to be a restriction when creating
DFDL xsds.
Regards
Steve Hanson
Programming Model Architect, WebSphere Message Brokers,
OGF DFDL WG Co-Chair,
Hursley, UK,
Internet: smh@uk.ibm.com,
Phone (+44)/(0) 1962-815848
----- Forwarded by Steve Hanson/UK/IBM on 22/10/2009 18:12 -----
From:
Steve Hanson/UK/IBM
To:
Alan Powell/UK/IBM@IBMGB
Cc:
dfdl-wg@ogf.org
Date:
21/10/2009 10:39
Subject:
Re: [DFDL-WG] DFDL Scoping v6
Alan
1) There's a rule that got absorbed into the end of rule 2 of the
combining rules. The rules are also specific to element ref -> global
element -> simple type. They need to be generalised to handle the four
combination cases you cite. Here's an amended set:
Rules
1. Create an empty working set of "explicit" properties. Create an
empty working set of "default" properties.
2. Move to the innermost schema component in the chain of
references.
3. Assemble its directly relevant "explicit" properties from its local
dfdl:ref (if present) and its local properties (if present), the latter
overriding the former (that is, local wins). Combine these with the
current working set of "explicit" properties. It is a schema definition
error if there is the same property appears twice. Result is a new working
set of "explicit" properties. Obtain directly relevant "default"
properties from in-scope unnamed dfdl:format block (if present). Combine
these with the current working set of "default" properties, the latter
overriding the former (ie, inner wins). Result is a new working set of
"default" properties.
4. Move to the schema component that references the current component,
and repeat step 3. If there is no referencing component, move to step 5.
5. Validate the resultant set of properties. The "explicit"
properties take priority, "defaults" only used when no "explicit" is
present. It is a schema definition error if a required property is in
neither the "explicit" nor the "default" working sets.
2) I think we should also define the property term "required". I think
"directly relevant" could be replaced by "applicable" (I know "directly
relevant" was my term :)
3) In Fig 5 you have dfdl:lengthKind on a xs:sequence - that is no longer
allowed.
4) In Fig 5 I think you should add an extra applicable property to the
dfdl:format in schema 1, to show how it gets picked up. Otherwise you are
not showing how all the rules are being applied, and the statement "
Nothing from the default dfdl:format block in SCHEMA1" will be
mis-interpreted.
Regards
Steve Hanson
Programming Model Architect, WebSphere Message Brokers,
OGF DFDL WG Co-Chair,
Hursley, UK,
Internet: smh@uk.ibm.com,
Phone (+44)/(0) 1962-815848
From:
Suman Kalia
participants (1)
-
Steve Hanson