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 5108 - sml 4.3.1 sml:acyclic
Summary: sml 4.3.1 sml:acyclic
Status: RESOLVED FIXED
Alias: None
Product: SML
Classification: Unclassified
Component: Core (show other bugs)
Version: unspecified
Hardware: PC Windows XP
: P2 normal
Target Milestone: LC
Assignee: Valentina Popescu
QA Contact: SML Working Group discussion list
URL:
Whiteboard:
Keywords: editorial
Depends on: 4793
Blocks:
  Show dependency treegraph
 
Reported: 2007-09-30 19:16 UTC by John Arwe
Modified: 2007-12-04 20:21 UTC (History)
0 users

See Also:


Attachments

Description John Arwe 2007-09-30 19:16:58 UTC
Separate the concerns
from:
Model validators that conform to this specification MUST support the sml:acyclic attribute on any <xs:complexType> element in a schema document. 
to:
Model authors MAY specify the sml:acyclic attribute on any <xs:complexType> element in a schema document. 
Model validators that conform to this specification MUST support the sml:acyclic attribute.

from:
This is a boolean attribute and its value can be either true or false.
to: (re-use text from 4.1.1.1 SML Reference)

add: pointer to notation used for defining xml schema elements in 2.x. We are using its notation ([],{}) in 4.1.1.1 SML Reference, in sml:acyclic, in other places too.

4.3.1.1 Mapping from Schema
Since xs:anyType has no value for this, we need to state that its value is false.  i.e. set the default to provide a base case for the recursive definition.

headings are not consistent in the least between 4.1.x and 4.2.x.
4.3.1.1 Mapping from Schema seems to be the equivalent of 4.1.1.1 Ref Defs/SML Ref, 4.3.1.2+3 equiv? to 4.1.2.  There is probably a sensible cleavage, like syntactic definition and semantics, that apply to each one.  There should be a consistent structure so it doesn't get in the way of readers comprehension.

Not sure what the distinction is between 4.3.1.2 Rules and 4.3.1.3 Validation.  A validator would have to enforce the constraints in both sections, no?  They both seem like statement of semantics, suggest combining and calling them Semantics.

4.3.1.2 Rules
from: "...but all derived types of an acylic reference type are     acyclic..."
to  : "...but all derived types of an acylic reference type must be acyclic..."
Comment 1 Virginia Smith 2007-11-01 23:49:44 UTC
These changes depend on bug 4639 so I'm removing the editorial keyword and adding the dependency.
Comment 2 James Lynn 2007-11-06 02:03:14 UTC
Regarding the last change from "derived types of an acylic reference type are acyclic..." to "derived types of an acylic reference type must be acyclic..." I suspect there is a correct way to say this in terms of how Schema handles derived types, but appeal to our Schema experts for advice.
Comment 3 John Arwe 2007-11-29 18:58:59 UTC
Most of the original comments are satisfied by the proposal for 4793 at 
http://lists.w3.org/Archives/Public/public-sml/2007Nov/0326.html

Separation of concerns: 4793 removes separate responsibilities for validators and authors, so covered.
true/false: 4793 covers
add: pointer to notation used  ... I do think this needs to be done ultimately; 4793 did not address this in copies of the proposal I saw
anyType remark: I forced 4793 to cover it.
headings are not consistent: editorial, assume 4793 covers it but did not check.  I trust you guys once the inconsistency is pointed out to fix it.
distinction between 4.3.1.2 and 4.3.1.3: covered by 4793
are -> must be: covered by 4793

ok if we want to make this editorial once 4793 is accepted, assuming its fix still covers these points in substantively the same manner as the uri above.
Comment 4 Valentina Popescu 2007-12-04 20:21:26 UTC
all fixes required by this defect have been applied under defect http://www.w3.org/Bugs/Public/show_bug.cgi?id=4793