[DFDL-WG] Fw: DFDL Scoping v6

Thu Oct 22 12:40:13 CDT 2009

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 at 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 at IBMGB
Cc:
dfdl-wg at 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 at uk.ibm.com,
Phone (+44)/(0) 1962-815848

From:
Suman Kalia <kalia at ca.ibm.com>
To:
Alan Powell/UK/IBM at IBMGB
Cc:
dfdl-wg at ogf.org, dfdl-wg-bounces at ogf.org
Date:
21/10/2009 03:53
Subject:
Re: [DFDL-WG] DFDL Scoping v6
Sent by:
dfdl-wg-bounces at ogf.org

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.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: 
Alan Powell <alan_powell at uk.ibm.com> 
To: 
dfdl-wg at ogf.org 
Date: 
10/20/2009 10:20 AM 
Subject: 
[DFDL-WG] DFDL Scoping v6 
Sent by: 
dfdl-wg-bounces at ogf.org

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 at 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 

--
 dfdl-wg mailing list
 dfdl-wg at ogf.org
 http://www.ogf.org/mailman/listinfo/dfdl-wg [attachment 
"ogf-dfdl-new-scoping-rules-with-default-V6.doc" deleted by Steve 
Hanson/UK/IBM] [attachment 
"ogf-dfdl-new-scoping-rules-with-default-V6_SKK.doc" deleted by Steve 
Hanson/UK/IBM] --
  dfdl-wg mailing list
  dfdl-wg at ogf.org
  http://www.ogf.org/mailman/listinfo/dfdl-wg

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/dfdl-wg/attachments/20091022/328448ce/attachment.html 