[Bug 5636] why prohibit rules on local decls/defs described by other specs?

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





------- Comment #1 from johnarwe@us.ibm.com  2008-04-16 13:41 -------
I found the earlier discussion that Sandy vaguely remembered having on last
week's call.  It was at the Jan 2008 F2F, and in
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5417

One thing I see in this discussion is that the proposal
http://www.w3.org/Bugs/Public/attachment.cgi?id=521&action=view , eventually
adopted with modifications, appears to NOT address all of the 5417's original
points.  At best, it partially addresses point 3.  We got side-tracked onto
different, but still valid, issues when discussing 5417.

This discussion fundamentally has 2 prongs:

Prong 1: Consistency in the text about where SML intends to allow rule
attachment.  My sense from working group discussions of its intent to define
rule attachment for each of the following:
P1a - GEDs: yes (pretty clear)
P1b - GTDs: yes (pretty clear)
P1c - Local EDs: no (pretty clear)
P1d - Local TDs: no (pretty clear)
P1e - Anonymous TD as a child of a GED: not sure 
P1f - Restriction from GED with rules attached to a Local ED: no (pretty clear)

Note that P1e is mentioned explicitly in at least one place, both before and
after 5417 was fixed, namely (LC draft) 6.3.2 bullet 1.

For this prong, the following changes would be needed if the bullets above are
indeed the intent of the working group:

Prong 1 change 1:
6.3 Rules Associated with Schema Components
from: SML defines a new property for every        complex type definition
schema 
to:   SML defines a new property for every global complex type definition
schema 
from: component and every        element declaration schema component. 
to:   component and every global element declaration schema component. 
Need to add P1e if that case is intended to be covered too.

Prong 1 change 2:
6.3.1 Mapping from schema, paragraph 2
Need to add P1e if that case is intended to be covered too.
We likely should be clearer that "embed" here means as a first child of
appinfo.  If someone created components equivalent to appinfo/ackbar/sch:schema
I get the impression that the wg would not expect those to be processed by SML.

Prong 1 change 3:
6.3.1 Mapping from schema, paragraph 3
Add to end: The local-rules of all other schema components is the empty set. 
This could also be accomplished by adding a new bullet 4 to the list as an
Otherwise.
Need to add P1e to first sentence if that case is intended to be covered too.

Prong 1 change 4:
6.3.1 Mapping from schema, bullet 3
from: If the schema component is a        complex type definition
to  : If the schema component is a global complex type definition
Need to add P1e to first sentence if that case is intended to be covered too.

Prong 1 change 4:
6.3.1 Mapping from schema, bullet 3.a
from: component's {base type definition} is a        complex type definition
to:   component's {base type definition} is a global complex type definition
Need to add P1e to first sentence if that case is intended to be covered too.

Prong 1 change 5:
6.3.2 Schema Validity Rules, bullet 1
If P1e is intended to be covered, leave as is; else, remove it from existing
text.

Prong 1 change 5:
6.3.2 Schema Validity Rules, bullet 2
from: If a        complex type D is derived
to:   If a global complex type D is derived

Prong 1 change 6:
6.3.2 Schema Validity Rules, bullet 2
from: from        {base type definition} B 
to:   from global {base type definition} B 

Prong 1 change 7:
If P1e is intended to be covered too, may need new bullets corresponding to
6.3.2 Schema Validity Rules, bullets 2 and 3.

Prong 1 change 8:
6.3.3 Instance Validity Rules, bullet 1
from: in {rules} of a        complex-type definition CT
to  : in {rules} of a global complex-type definition CT

-----------------------------------------
Prong 2: Whether or not the working group intends to make it intentionally
difficult to define rules on the "no" cases amongst P1a-P1f in other specs that
would perhaps layer on top of SML 1.1.  On the 4/10 call, the subset of the
working group ready to express an opinion leaned away from interfering with
other specs covering cases for rule attachment that SML 1.1 does not cover
(e.g. P1c, P1d).  If that represents the intent of the working group, then the
following changes are suggested.

Prong 2 change 1:
6.3.1 Mapping from schema, paragraph 2
from: They MUST NOT be embedded in any other kind of schema component.
to  : SML assigns no meaning to them and stipulates no requirements on their 
      processing if they are embedded elsewhere.

Prong 2 change 2: (possibly optional, have not fully convinced myself yet)
6.3.1 Mapping from schema, paragraph 3
Add to end: The local-rules of all other schema components is the empty set. 
This could also be accomplished by adding a new bullet 4 to the list as an
Otherwise.

Prong 2 change 3:
6.3.2 Schema Validity Rules, bullet 1
Remove: It MUST be empty for any other schema component.
Alternative to removal (I think it would be easy for readers of the spec to
infer that we are actively preventing other specs from defining rule attachment
beyond that specified in SML 1.1, regardless of our actual intent):
from: It MUST be empty for any other schema component.
to:   It is a consequence of [6.3.1] that SML will not contribute to {rules}
for any other schema components.

Prong 2 change 3:
6.3.2 Schema Validity Rules, bullet 3
from: cannot be restricted to a local element declaration in D.
to  : cannot be restricted to a local element declaration in D without loss of
the {rules} contributed by B.  This case SHOULD be reported, and MAY be treated
as an error.

Prong 2 change 4:
6.3.2 Schema Validity Rules, bullet 3 note
from: It is             an error if all
to  : It is very likely an error if all

Prong 2 change 5:
6.3.2 Schema Validity Rules, bullet 3 note
Append to the non-list sentence: 
SML allows validators to accept this case as valid in order to allow future
specifications to compatibly layer on top of SML.  Such specifications may
define rule attachment for constructs such as local type declarations not
covered in this version of SML.  SML does not wish to automatically force
models  compliant with such future specifications to be declared invalid with
respect to SML.

Received on Wednesday, 16 April 2008 13:41:58 UTC