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 5543 - SML URI seems overconstrained
Summary: SML URI seems overconstrained
Alias: None
Product: SML
Classification: Unclassified
Component: Core (show other bugs)
Version: LC
Hardware: PC Windows NT
: P2 normal
Target Milestone: LC
Assignee: Kumar Pandit
QA Contact: SML Working Group discussion list
Keywords: externalComments, reviewerSatisfied
Depends on:
Reported: 2008-03-07 01:33 UTC by Pratul Dublish
Modified: 2008-09-04 18:27 UTC (History)
4 users (show)

See Also:

diff for shorthand pointer changes (181.17 KB, text/html)
2008-08-20 23:53 UTC, Kumar Pandit

Description Pratul Dublish 2008-03-07 01:33:22 UTC

3) The SMLURI thing seems overconstrained---why not just say it's a URI
   and be done with it?  What is gained by saying that
   e.g. http// is _not_ an
   SMLURI?  I reckon that's going to be _hugely_ confusing to users.
Comment 1 Kumar Pandit 2008-03-19 19:02:17 UTC
The main driver behind the development  SML is modeling complex services/systems and promote inter-operability between implementations when exchanging models. The groups charter ( 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.
Comment 2 Pratul Dublish 2008-03-31 23:17:01 UTC

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.
Comment 3 Kumar Pandit 2008-04-17 18:40:47 UTC
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).
Comment 4 Henry S. Thompson 2008-04-18 13:16:59 UTC
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.
Comment 5 John Arwe 2008-07-03 20:00:52 UTC
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 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).
Comment 6 Henry S. Thompson 2008-07-10 18:40:47 UTC
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, 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.
Comment 7 Pratul Dublish 2008-07-17 19:53:59 UTC
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.
Comment 8 Pratul Dublish 2008-07-24 19:33:28 UTC
Resolution in 7/24 call
Model validators MUST support schema-determined IDs for barename processing, any additional behavior is implementation define
Comment 9 Henry S. Thompson 2008-07-25 10:40:58 UTC
If lower-case 's' "schema-determined" covers DTDs as well as W3C XML Schema, I'm satisfied.
Comment 10 Henry S. Thompson 2008-07-26 19:06:32 UTC
Email to the public sml list suggests that DTD-based IDness is _not_ meant to be included in the proposed resolution.

Accordingly (see I am _not_ satisfied by the proposed resolution.
Comment 11 Pratul Dublish 2008-08-05 03:07:44 UTC
Resolution in 7/31 call:   align schema-determination of IDs with the xpointer framework spec. This is in addition to Comment #8 
Comment 12 Kumar Pandit 2008-08-07 18:58:12 UTC
resolution in conf call on 8/7/08:
The groups response is in email at:

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.
Comment 13 Kumar Pandit 2008-08-20 23:53:13 UTC
Created attachment 564 [details]
diff for shorthand pointer changes
Comment 14 Kumar Pandit 2008-08-20 23:55:43 UTC
fixed per resolution. Please refer to the attachment: "diff for shorthand pointer changes".
Comment 15 Sandy Gao 2008-08-21 03:39:49 UTC
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 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 In, 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 smlxpath1() scheme."

b. Remove bullet 5 from

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. ..."
Comment 16 Pratul Dublish 2008-08-21 18:37:22 UTC
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
Comment 17 Kumar Pandit 2008-08-21 21:39:54 UTC
fixed per comment# 16.
Comment 18 John Arwe 2008-08-22 13:00:03 UTC
(In reply to comment #16 and comment #17)
> (2) in Comment #15 will be considered post 2nd LC draft
is now being tracked as
Comment 19 Henry S. Thompson 2008-09-03 14:49:08 UTC
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)