I have updated the scoping proposal with the help of Steve and Stephanie. The main changes are to clarify the wording, define new terms, add more examples and propose disallowing multiple annotation at the same point (other than for selectors) 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 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
Some comments added in the document
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.ht...
Tel : 905-413-3923 T/L 969-3923
Fax : 905-413-4850 T/L 969-4850
Internet ID : kalia@ca.ibm.com
From:
Alan Powell
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 (3)
-
Alan Powell
-
Steve Hanson
-
Suman Kalia