This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 5428 - unclear passages
Summary: unclear passages
Status: RESOLVED FIXED
Alias: None
Product: SML
Classification: Unclassified
Component: Core (show other bugs)
Version: LC
Hardware: PC Windows XP
: P2 normal
Target Milestone: LC
Assignee: Kumar Pandit
QA Contact: SML Working Group discussion list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-01-25 23:15 UTC by John Arwe
Modified: 2008-02-01 08:11 UTC (History)
0 users

See Also:


Attachments

Description John Arwe 2008-01-25 23:15:56 UTC
(1) 4.4.1 sml:acyclic
"This attribute is of type xs:boolean and its actual value can be either true or false."
'actual value' is a precisely defined XML Schema term in this context, but there is no hint to a reader that anything other than the colloquial meaning should be applied.  It is defined in http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/#key-vv and should be cited.
It is in fact the use of this term that allows the SML spec to ignore the other 
lexically valid values that instances of the xs:boolean type can take on ("1","0") and not repeat the clauses used for sml:ref and sml:nilref involving collapsing of whitespace.

(2) 4.4.1.1 Mapping from Schema
from:     {acyclic}                of a complex type 
to  : The {acyclic} property value of a complex type 

(3) 4.5 Identity Constraints
from: XML Schema supports the definition of key, unique,    and key reference constraints
to  : XML Schema supports the definition of      uniqueness and     reference 
constraints
(this harmonizes them with XML Schema's actual terms, see http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/#cIdentity-constraint_Definitions )

(4) 4.5.1.1 Mapping from Schema, last paragraph
from: complex type D, who  is a restriction
to  : complex type D, that is a restriction

(5) 4.5.1.1 Mapping from Schema, last paragraph
then {SML identity-constraints definitions} of ED also contains members of {SML identity-constraints definitions} of EB.
This leaves open the question of "which members?  all?  any?" etc.  This question is answered in 4.5.1.2 step 6, probably should link to it for clarity.

(6) 4.5.1.2 Schema Validity Rules, item 1
from: XML        identity constraint 
to  : XML Schema identity constraint 
(2 places at least)

(7) 4.5.1.2 Schema Validity Rules, item 2
Inconsistent to say "{selector}" in item 1, and "The sml:field XPath expression" in item 2.  Looking at http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/#declare-key , {fields} would be the appropriate value if we go with the style of item 1.  The "expression" in item 2, regardless of its form, does need to be plural (multiple fields allowed per selector, if SML identity constraints are truly patterned after XSDL's).

(8) 4.5.1.2 Schema Validity Rules, item 2
"The sml:field XPath expression MUST conform to the amended BNF defined above for the selector XPath expression with the following modification,to allow smlfn:deref() functions, nested to any depth, at the beginning of the expression."  Tilt.  What I _think_ this is trying to say: xs:field's BNF needs the same modification that xs:selector needed (item 1), for the same reason, and wishes to re-use the DerefExpr production.  FWIW, item 1's words were clear enough to me.  I would just repeat them, and append words to say the production is the same.  As item 1 has, item 2 (desperately) needs to connect its text to the BNF that follows...all the more so because item 2 refers back to item 1's BNF.
Comment 1 Valentina Popescu 2008-01-31 20:50:48 UTC
reviewed in 01/31 meeting; resolution to mark editorial 
Comment 2 Kumar Pandit 2008-02-01 08:11:17 UTC
All changes applied as suggested except the following:

[7]
I got rid of {selector} and used sml:selector instead.

[8]
I reworded the field part to make it similar to the selector part.

The changes are aligned with the original intent.