Re: [Bug 4793] Restructure section 3.4 to follow the following 1) mapping from syntax to cannonical representation, 2) what constitutues a valid usage and 3) implications on instances. from Sandy Gao on 2007-09-18 (public-sml@w3.org from September 2007)

From: Sandy Gao <sandygao@ca.ibm.com>
Date: Tue, 18 Sep 2007 13:53:27 -0400
To: public-sml@w3.org
Message-ID: <OF43F5BB55.D8578A02-ON8525735A.00621300-8525735A.006246DE@ca.ibm.com>
Some of the bullets obviously messed up. Hope people can still tell what I 
meant.

And I shouldn't have used "substitutable for". I forgot this term was 
introduced in schema 1.1. Should have used "derived from" (as the current 
draft does).

Thanks,
Sandy Gao
XML Technologies, IBM Canada
Editor, W3C XML Schema WG
Member, W3C SML WG
(1-905) 413-3255 T/L 969-3255
 



Sandy Gao/Toronto/IBM@IBMCA 
Sent by: public-sml-request@w3.org
2007-09-18 11:12 AM

To
public-sml@w3.org
cc

Subject
Re: [Bug 4793] Restructure section 3.4 to follow the following 1) mapping 
from syntax to cannonical representation, 2) what constitutues a valid 
usage and 3) implications on instances.







The copy I'm looking at: 

http://dev.w3.org/cvsweb/~checkout~/2007/xml/sml/build/sml.html?content-type=text/html;%20charset=utf-8#sml_acyclic 


4.3 and 4.3.1 mostly look good. A couple of minor things: 

- In 4.3, the following sentence should be on a separate line: 

{acyclic} An xs:boolean value. Required.

(Or maybe it should be bulleted, like the {target *} properties.) 

- In 4.3.1.2, I would want to avoid "a cyclic type", which a) isn't 
defined, and b) sounds too similar to "acyclic type". Some rewording may 
be useful. 


4.3.2 is less complete. If we don't have time to finish it, I think we 
should still use the new section structure, but move existing text into 
those sections. (The old text wasn't consistent when discussing Particles, 
so "and every Particle component" should be removed from 4.3. 4.3.2 can be 
something like ... 

(Note that the only *real* change is about inheriting target* from a 
restricted base type. This was incompletely and wrongly specified anyway. 
e.g. If base has a local element with target* and derived has a reference 
to a global element with the same name, how to inherit? And this kind of 
magic inheritance doesn't happen in schema; we may want to stay in-sync 
with schema.) 

(After writing the following, I think we need 2 new issues opened: 1. a 
similar rewrite for key/keyref/unique, and 2. when to all inherit these 
constrains. I will open them.) 

(The following is obviously more radical change than what I planned. Hope 
people find it useful.) 

4.3.2 Constraints on Targets 
SML supports three attributes: sml:targetElement, sml:targetRequired, and 
sml:targetType, for constraining the target of a reference. These three 
attributes are collectively called sml:target* attributes and they MUST be 
supported on global and local element declarations. 
4.3.2.1 Mapping from schema 
{target element} is as specified by the appropriate case among the 
following: 
If sml:targetElement is present, then its actual value MUST resolve to a 
global element declaration G, and {target element} is G. 
Otherwise if {substitution group affiliation} is not absent, then {target 
element} is the same as that of the {substitution group affiliation}. 
Otherwise {target element} is absent.
{target required} is as specified by the appropriate case among the 
following: 
If sml:targetRequired is present, then {target required} is the actual 
value this attribute. 
Otherwise  (sml:targetRequired is not present) if {substitution group 
affiliation} is not absent, then {target required} is the same as that of 
the {substitution group affiliation}. 
Otherwise {target element} is false.
{target type} is as specified by the appropriate case among the following: 

If sml:targetType is present, then its actual value MUST resolve to a 
global type definition T, and {target type} is T. 
Otherwise (sml:targetType is not present) if {substitution group 
affiliation} is not absent, then {target type} is the same as that of the 
{substitution group affiliation}. 
Otherwise {target element} is absent.
4.3.2.2 Rules 
Model validators that conform to this specification MUST enforce the 
following: 
1.      If a global element declaration S has a {substitution group 
affiliation} G, then all the following are true:
If G has {target element} TEG, then S has {target element} TES and TES is 
the same as TEG or is in the substitution group of TEG. 
If G has {target required} true then S also has {target required} true. 
If G has {target type} TTG, then S has {target type} TTS and TTS is 
validly substitutable for TTG. 
If 2 element declarations E1 and E2 have the same {namespace name} and 
{name} and they are both contained (directly, indirectly, or implicitly) 
in a content model of a complex type, then E1 and E2 have the same {target 
element}, {target required}, and {target type}. 
For a complex type D derived by restriction from its {base type 
definition} B, if ED is included by D and EB is included in B and ED and 
EB satisfies the "NameAndTypeOK" constraint (see "Schema Component 
Constraint: Particle Valid (Restriction) ", section 3.9.6, "Constraints on 
Particle Schema Components", [XML Schema Structures] for XML Schema's 
definition of valid restrictions), then all the following are true: 
If EB has {target element} TEB, then ED has {target element} TED and TED 
is the same as TEB or is in the substitution group of TEB. 
If EB has {target required} true then ED also has {target required} true. 
If EB has {target type} TTB, then ED has {target type} TTD and TTD is 
validly substitutable for TTB.
The above condition #2 has been defined to reduce the implementation 
burden on model validators for verifying that the use of sml:target* 
attributes is consistent across derivation by restriction. These 
conditions enable model validators to find the restricted particle for a 
restricting particle using a simple name match when sml:target* attributes 
are specified for these particles. 
In the absence of the above conditions, it is extremely difficult for SML 
validators to verify consistent use of sml:target* attributes across a 
base type and its restricted derived type. In order to verify consistent 
use of an sml:target* attribute on a restricted particle in the base type 
and its restricting particle in a restricted derived type, it is necessary 
to connect the particles in the derived type with  those from the 
restricted base type. However, this level of support is not provided by 
most XML Schema frameworks; thus most SML validators would otherwise need 
to duplicate large parts of XML Schema's compilation logic to verify 
consistent usage of sml:target* attributes across derivation by 
restriction. 
4.3.2.3 Validation 
If an element declaration E has {target element} TE, then each element 
instance of E that is also a resolved SML reference MUST target an element 
that is an instance of TE or an instance of some global element 
declaration in the substitution group of TE. 
If an element declaration E has {target required} true, then each element 
instance of E that is also an SML reference MUST target some element in 
the model, i.e. no instance of E can be a null or unresolved SML 
reference. 
If an element declaration E has {target type} TT, then each element 
instance of E that is also a resolved SML reference MUST target an element 
whose [type definition] is TT or a type substitutable for TT. 

Thanks,
Sandy Gao
XML Technologies, IBM Canada
Editor, W3C XML Schema WG
Member, W3C SML WG
(1-905) 413-3255 T/L 969-3255



bugzilla@wiggum.w3.org 
Sent by: public-sml-request@w3.org 
2007-09-17 12:32 PM 


To
public-sml@w3.org 
cc

Subject
[Bug 4793] Restructure section 3.4 to follow the following 1) mapping from 
syntax to cannonical representation, 2) what constitutues a valid usage 
and 3) implications on instances.









http://www.w3.org/Bugs/Public/show_bug.cgi?id=4793


james.lynn@hp.com changed:

          What    |Removed                     |Added
----------------------------------------------------------------------------
            Status|NEW                         |ASSIGNED




------- Comment #2 from james.lynn@hp.com  2007-09-17 16:32 -------
This section is now 4.3. This bug requires more than restructuring and 
will
need extensive rewriting in section 4.3.2 Constraints on Targets. Some
restructuring has been done on both 4.3.1 and 4.3.2.
Received on Tuesday, 18 September 2007 17:53:41 UTC