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 5099 - sml section 4.1 References most text should be moved into other sections
Summary: sml section 4.1 References most text should be moved into other sections
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:
Depends on: 5091
Blocks:
  Show dependency treegraph
 
Reported: 2007-09-30 16:37 UTC by John Arwe
Modified: 2007-11-19 22:18 UTC (History)
0 users

See Also:


Attachments

Description John Arwe 2007-09-30 16:37:32 UTC
4.1 is intended to be explanatory; its limited possibly normative statements are already covered in other normative sections excepts as noted below.

Proposal: 

Excerpt 1: move to non-normative section
XML documents introduce boundaries across content that needs to be treated as a unit. XML Schema does not have any support for inter-document references. SML extends XML Schema to support inter-document references and a set of constraints on inter-document references.

Support for inter-document references includes:

    *      Multiple addressing schemes for representing references.
    *      Constraints on the type of a referenced element.
    *      The ability to define key, unique, and key reference constraints across inter-document references. 
An SML reference is a link from one element in an SML model to another element from the same model. 

Excerpt 2: update as follows move to non-normative section
from
It can be represented by using a variety of schemes, such as 4.2.1 URI Scheme and Endpoint References (EPRs) [WS-Addressing Core]. 
to
It can be represented by using a variety of reference schemes, including those defined in this specification. 

Excerpt 3: delete, duplicates content already in 4.2
SML does not mandate the use of any specific scheme for representing references; implementations are free to choose suitable schemes for representing references.  

Excerpt 4: keep in 4.1, not covered elsewhere that I can see
References MUST be supported by model validators that conform to this specification. 

Excerpt 5: delete, duplicates content already in 4.2
An SML reference MAY use one or more reference schemes.

Excerpt 6: delete, duplicates content already in 4.1.1.1
Reference elements MUST be identified by sml:ref="true" or sml:ref="1" where sml:ref is a global SML attribute whose declaration is as follows:

Excerpt 7: delete, duplicates content already in schema
<xs:attribute name="ref" type="xs:boolean" />

Excerpt 8: reword and move to non-normative section
from
Although either sml:ref="true" or sml:ref="1" can be used to identify an SML reference element, for the sake of brevity and consistency, the rest of this specification uses sml:ref="true" in examples and other definitions.
to
Although its normative definition allows several syntaxes to be used to identify an SML reference element, for the sake of brevity and consistency, this specification uses sml:ref="true" in examples and text.

Excerpt 9: merge into 4.1.1.1, not covered elsewhere that I can see
An element that has sml:ref="true" MUST be treated as a reference element. 
Changing 4.1.1.1 content from
"An element information item in an SML model instance document is an SML reference if and only if"
to
"An element information item in an SML model instance document MUST be treated as an SML reference if and only if"
would be my approach.

Excerpt 10: move to 4.1.1.1, not covered elsewhere that I can see
This mechanism enables schema-less identification of reference elements, i.e., reference elements can be identified without relying on PSVI.

Excerpt 11: keep, (optionally under new non-normative h3 Reference Example)
from "The following example illustrates" to end of example just before "Null references are different from empty references"

Excerpt 12: delete, should have been nuked when "empty ref" was excised
Null references are different from empty references. An empty reference is a normal reference that just happen to be empty. For a null reference, the content of that reference is intentionally left empty, as an explicit declaration of intent from the document author that the reference must be empty.

Excerpt 13: reword
from "...illustrates the use of sml:ref. Consider..."
to   "...illustrates the use of SML references. Consider..."

Excerpt 14: reflow so it is not truncated when printing
Example following "content model and this can be used to mark instances of EnrolledCourse as reference elements as shown below:"
split the sml:uri value just before #xmlns

Excerpt 15: edit
from "...references are represented using         URI and EPR schemes,"
to   "...references are represented using the SML URI and EPR schemes,"

Excerpt 16: edit
from "...marked as a null reference if it defines the sml:nilref="true"..."
to   "...marked as a null reference if it specifies   sml:nilref="true"..."

Excerpt 17: edit
from "By setting  the reference null, the document author ..."
to   "By specifying a null reference, the document author ..."

Excerpt 18: edit to fix wildly incorrect current content
from "Student doesn't have an EnrolledCourse with a name PHY101 and grade A"
to   "Student element does not refer to any target element.  Specifying a null reference does not have any SML-defined effect on the interpretation of element in non-SML contexts.  In particular, in this case, SML says nothing about the interpretation of the <Grade> and <Name> elements.  Any such interpretation is left to the application, its usage context, other specifications, etc."
Comment 1 John Arwe 2007-09-30 16:42:43 UTC
Excerpt 19: edit
from "Multiple addressing schemes for representing references"
to   "Multiple reference  schemes for representing references"

Excerpt 20: add new bullet to list from excerpt 20
"An extensibility mechanism allowing new reference schemes to be defined, conceptually similar to the relationship between URIs and URI schemes"
Comment 2 John Arwe 2007-09-30 18:40:29 UTC
If 5099 excerpt 11 suggestion to make the example a new H3 is taken, update ref in "For example, if the reference element in 4.1 References is represented using the URI scheme, an instance of EnrolledCourse will appear as follows:" to point to it.
Comment 3 Valentina Popescu 2007-11-07 04:38:52 UTC
All editorial updates have been applied.

The exmple under section 4.1 was moved under Appendices : 
D. SML References Sample (Non-Normative)

Not covered :
Excerpt 1: the move to non-normative section

Reason for not moving under non-normative:
1. This is already moved under Terminology : An SML reference is a link from one element in an SML model to another element
from the same model. 
2. This is already moved under section 4, SML References bullet:
XML documents introduce boundaries across content that needs to be treated as a
unit. 
3. I moved under 4.2 Reference scheme this part:
An SML reference MAY be represented by using a variety of schemes >>, including those defined in this specification.

4. What is left out of 4.1 seems to be well aligned with this normative section :

4.1 References

Support for SML references in an SML model includes:

   1.  Multiple reference schemes for representing references.
   2. An extensibility mechanism allowing new reference schemes to be defined, conceptually similar to the relationship between URIs and URI schemes.
   3. Constraints on the type of a referenced element.
   4. The ability to define key, unique, and key reference constraints across SML references.

References MUST be supported by model validators that conform to this specification.
Comment 4 Pratul Dublish 2007-11-12 04:16:32 UTC
IMO, the first two bullets in 4.1 should be removed

   1.  Multiple reference schemes for representing references.
   2. An extensibility mechanism allowing new reference schemes to be defined,
conceptually similar to the relationship between URIs and URI schemes.

As written, they give the impression that multiple schemes and extensibility mechanisms for new reference schemes are required.  Secondly, I don't understand the last phrase in 2 " conceptually similar to the relationship between URIs and URI schemes" - what relationship between URI and URI scheme is being alluded to here? 
Comment 5 Kumar Pandit 2007-11-14 08:32:30 UTC
I agree with comment #4.

If we want to retain #1, it could be changed as:

from: 1.                     Multiple reference schemes for representing references.
to  : 1.  The ability to use multiple reference schemes for representing references.



If we want to retain #2, it could be changed as:

from: 2. An extensibility mechanism allowing new reference schemes to be
defined, conceptually similar to the relationship between URI references and
URI schemes.
to  : 2. An extensibility mechanism allowing new reference schemes to be
defined.

I have also noted the same in bug# 4788 comment# 3.
Comment 6 John Arwe 2007-11-15 18:46:37 UTC
Ok with comment 5's changes.

wrt comment 4 and what is being alluded to, it is quite simple once you get over the (admittedly large) rfc3986 hump.  Each URI as a scheme component.  The definition of URI schemes is independent of the generic URI syntax represented in 3986.  Thus a URI (URI reference, to be precise) consists logically of a "slot" for a URI scheme along with "slots" for other components like query and fragment.  Conceptually there is a "uses" relationship between a URI instance and a URI scheme definition.  The SML analog is that each SML reference instance uses (is compliant with, would be recognized by an omniscient consumer as being an example of) zero or more SML reference schemes.  SML reference scheme definitions (in general) are independent of the SML specs.
Comment 7 Valentina Popescu 2007-11-19 22:18:23 UTC
Fixed as per comments #5, #6


Support for SML references in an SML model includes:

   1.The ability to use multiple reference schemes for representing references.
   2.An extensibility mechanism allowing new reference schemes to be defined.
   3.Constraints on the type of a referenced element.
   4.The ability to define key, unique, and key reference constraints across SML references.