The main driver behind the development  SML is modeling complex services/systems and promote inter-operability between implementations when exchanging models. The groups charter (http://www.w3.org/2007/03/SML_Charter.html) explains this well.

The SML reference is quite flexible; it allows any reference scheme to be defined and used. This allows a wide variety of applications to define reference schemes suitable for their application domain. The SML spec does not prevent one from defining and using a reference scheme that allows any URI/IRI to be used.

Although the SML reference is flexible, the SML URI scheme is designed for a specific purpose. The main goal of SML URI scheme is to promote interoperability between implementations. This means that all conforming implementations should be able to produce and consume it without undue implementation burden. Allowing any URI to be used in SML URI scheme and yet meet the full interoperability goal will require all implementations to support all xpointer schemes (currently there are about 25 registered) and all other ways of encoding fragment identifiers. This will make it much harder to write conforming SML implementations.

The working group adopted a balanced approach to the above problem. Allowing any ref scheme to be defined/used gives flexibility to applications and requiring the easy to implement SML URI scheme for exchanging models promotes interoperability.

I am not sure I understand why users are going to be confused given that the definition of the SML URI scheme clearly says that only the smlxpath1() scheme is allowed. If it helps, the WG should consider adding a note to the section that defines the SML URI scheme to clarify the intent behind it.

The change in status should cause email to be sent to the originator of this
issue, to whom the following request is addressed.


Resolution in F2F meeting on 3/31 - the WG felt that this should be considered for the next version of SML. The SML URI Reference Scheme has been defined to ensure interoperability between implementations. To achieve interop for bare names, we would need to require PSVI or DTDs, or application-defined identifiers. None of these are good for interop. Plus, it is not clear that bare names are defined for invalid XML documents, but we need to allow invalid documents in models. Of course, it is possible to define an application/domain specific SML Reference Scheme that supports bare names


Please review the changes adopted and let us know if you agree with this
resolution of your issue, by adding a comment to the issue record and changing
the Status of the issue to Closed. Or, if you do not agree with this
resolution, please add a comment explaining why. If you wish to appeal the WG's
decision to the Director, then also change the Status of the record to
Reopened. If you wish to record your dissent, but do not wish to appeal the
decision to the Director, then change the Status of the record to Closed. If we
do not hear from you in the next two weeks, we will assume you agree with the
WG decision.

resolution (conf call on 4/17/2008): Resolve as 'later' and remove the 'decided' keyword because the 2 week response period has elapsed (see comment# 2).

This is not acceptable.  You have not addressed my example at all, and the xpointer issue is FUD pure and simple.  You will hugely inconvenience your users if they can't use barename fragment identifiers.  Please think again.

Henry, just following up on this from the f2f:

action item: "john to ask henry to describe what processing a minimally conforming xml processor must do wrt ID processing"

related to http://www.w3.org/Bugs/Public/show_bug.cgi?id=5545 according to 6/24 minutes, I think in fact we agreed to do this under 5543 (5545 is now marked reviewerSatisfied).  5543 is the bare names issue.

On the working group's 7/3 call it decided to ask for a response by July 10.  If the working group receives no response by that time, it may choose to continue to publish the next LC draft with this issue in its current state (Resolved-Later, i.e. not in 1.1).

A minimally conforming XML processor _must_ identify attribute types, wrt any attribute declarations it reads.  A minimally conforming XML processor _must_ read all attributes declarations in the internal subset which occur before the first external parameter entity reference.  So it is easy for authors to _force_ a minimally conforming XML processor to recognise their IDs.  See for example the schema document for XML schemas, at http://www.w3.org/2001/XMLSchema.xsd, which includes (redundant) attribute declarations for all its ID-type attributes in the internal subset.  My objection stands -- I will formally object if SML goes forward without support for barename pointers.

7/17 call - summary of discussion for record ONLY. The WG appears to be leaning towards the following but this has NOT been formally approved as yet

 because a) not all xml processors are *required* to expose DTD IDness, and b) schema IDs may or may not be recognized depending on whether you actually do schema validation.04 01the best we can do is probably to allow bare name, but makes its behavior impl-defined.
<Sandy> Pratul: what does impl-defined mean? can a processor just always return null?
<Sandy> Sandy: a little stronger. the feature is required and processors are expected to try their best to resolve it. e.g. if schema validation was performed, then schema ids should be recognized.

Resolution in 7/24 call
Model validators MUST support schema-determined IDs for barename processing, any additional behavior is implementation define

If lower-case 's' "schema-determined" covers DTDs as well as W3C XML Schema, I'm satisfied.

Email to the public sml list http://lists.w3.org/Archives/Public/public-sml/2008Jul/0052.html suggests that DTD-based IDness is _not_ meant to be included in the proposed resolution.

Accordingly (see http://lists.w3.org/Archives/Public/public-sml/2008Jul/0053.html) I am _not_ satisfied by the proposed resolution.

Resolution in 7/31 call:   align schema-determination of IDs with the xpointer framework spec. This is in addition to Comment #8 

resolution in conf call on 8/7/08:
The groups response is in email at: http://lists.w3.org/Archives/Public/public-sml/2008Aug/0008.html

The SML WG believes that the email addresses this issue fully.

I'm changing its status accordingly. The change in status should cause email to be sent to the originator of this issue, to whom the following request is addressed.

Please review the comment text and let us know if you agree with this resolution of your issue, by adding a comment to the issue record. Or, if you do not agree with this resolution, please add a comment explaining why. If we do not hear from you in the next two weeks, we will assume you agree with the WG decision.

Created attachment 564 [details]
diff for shorthand pointer changes

fixed per resolution. Please refer to the attachment: "diff for shorthand pointer changes".

A couple of comments.

1. The new bullet "ii" doesn't read very well, and it seems to have a contradiction.

I think it'd be better to say "..., then the reference target is the element identified ..."

Part of the first sentence takes the form "A is B", then the second sentence says "A may be C". This looks like a contradiction to me. I think you want to say "if there is a schema-determined ID [link], then A is B; otherwise it is implementation defined whether A has no value or whether A is C."

2. The responsibility division between 4.3.1 and 4.3.1.1 are not very clear.

4.3.1 goes through effort to compute the document (D) that potentially contains the target, but D is not passed to 4.3.1.1. In 4.3.1.1, it mentioned the concept of "Document context", which is not a term defined in XPointer Framework.

I think it'd be easier to understand if

a. Change bullet i in 4.3.1 to something like "If ..., then the reference target is obtained by applying the fragment component to D, as defined in section 4.3.1.1 smlxpath1() scheme."

b. Remove bullet 5 from 4.3.1.1

c. Change (the current) bullet 6 to "For a given document D, the element targeted by a scheme instance is obtained by applying the location path in SMLXPath1_SchemeData to the root element of D. ..."

Fix (1) in Comment #15 by 
If the fragment component complies with the Shorthand Pointer syntax, then:
If a target can be identified based on XML Schema determined ID, the the target is the element identified based on XML Schema determined ID by the Shorthand Pointer. 
 If a target cannot be identified based on XML Schema determined ID then it is implementation-defined whether the reference target is identified based on other criteria allowed for Shorthand Pointers

(2) in Comment #15 will be considered post 2nd LC draft

fixed per comment# 16.

(In reply to comment #16 and comment #17)
> (2) in Comment #15 will be considered post 2nd LC draft
> 
is now being tracked as http://www.w3.org/Bugs/Public/show_bug.cgi?id=5980

I can live with the text of the 'September 12' editors' draft as it stands today.  I would be happier if you added "Implementations SHOULD support DTD-determined IDness and SHOULD support xml:id-determined IDness." at the end of 4.3.1 2)c)B)