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 5542 - How are SML URIs absolutized
Summary: How are SML URIs absolutized
Alias: None
Product: SML
Classification: Unclassified
Component: Core+Interchange Format (show other bugs)
Version: LC
Hardware: PC Windows NT
: P2 normal
Target Milestone: LC
Assignee: Virginia Smith
QA Contact: SML Working Group discussion list
Keywords: externalComments, reviewerSatisfied
Depends on:
Blocks: 5707
  Show dependency treegraph
Reported: 2008-03-07 01:32 UTC by Pratul Dublish
Modified: 2008-11-06 00:45 UTC (History)
2 users (show)

See Also:


Description Pratul Dublish 2008-03-07 01:32:09 UTC

2) It's not stated whether SMLURIs are interpreted wrt a base URI if
   they are not absolute, i.e. how they are absolutized.
Comment 1 Kumar Pandit 2008-03-13 19:51:24 UTC
resolution (3/13 conf call): 

For quick reference, the relevant text in the LC draft is shown below:

From section "4.3.1 SML URI Reference Scheme", bullet 2.a:

a. If the URI is a relative reference, then use an implementation-dependent base URI to resolve it to an URI.

The SML WG believes that the current text in the LC draft resolves 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 current LC 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 2 Henry S. Thompson 2008-04-18 14:00:29 UTC
I'm very unhappy with the fix -- surely the right thing to do is a) require the use of the base URI property and b) encourage, if not mandate, XML Base support.
Comment 3 C. M. Sperberg-McQueen 2008-06-12 20:06:26 UTC
Judging by comment #2, I think it must have been an oversight that
Henry as the originator did not reopen this issue to indicate dissatisfaction,
as suggested in comment #1.  To simplify tracking, I'm going to reopen it
then, partly on Henry's behalf and partly on my own, since I have been
persuaded that he is right and that the SML WG should adopt the plan
given in comment #2.

Unfortunately, I don't know what changes need to be made to the keywords
to do the job properly, so the keywords may be out of synch with what
they need to be.
Comment 4 Pratul Dublish 2008-07-17 18:31:58 UTC
As per the discussion in Edinburgh, the issue spans both IF and core. See John's proposal for a possible update to IF 
Comment 5 Pratul Dublish 2008-07-17 19:19:40 UTC
Resolution in 7/17 call for IF spec
adopt the proposal a) bullets 2-5 in John's email  

   2. Support for smlif:baseURI is optional for smlif producers 
   3. Support for smlif:baseURI is optional for smlif consumers 
   4. Support for xml:base is required for smlif producers 
   5. Support for xml:base is optional for smlif consumers

 and b) a statement that "the intention of the authors of this spec is to deprecate this feature if a future version is introduced"  
Comment 6 Pratul Dublish 2008-07-17 19:42:14 UTC
In addition to Comment #5, the WG agreed to the following additional changes

In IF, we additionally describe how [base URI] is computed, from either smlif:baseURI or xml:base, whichever is supported by the consumer.
In core (definition of SML URI scheme), require the use of [base URI] property and say that its computation is  impl-defined, but need to be consistent with the 4 steps described by the relevant RFC.
Comment 7 Henry S. Thompson 2008-07-24 15:58:47 UTC
I can live with this compromise, provided
 a) You deprecate the use of smlif:baseURI forthwith for producers (after all, it's only being supported now for backwards compatibility, so it should not be a problem to strongly suggest that new docs should not use it);
 b) The algorithm for computing [base URI] makes clear that in the presence of _both_ annotations, xml:base 'wins'
Comment 8 C. M. Sperberg-McQueen 2008-07-24 17:30:43 UTC
For what it's worth, I can also live with the compromise described
in comment #5 and comment #6, which I understand as being 
essentially what was proposed by John Arwe in his mail of 9 July at
(If there's an important difference, then I've missed something
and this statement of agreement is worthless.)

Like Henry in comment #7 and John in the email mentioned, 
I think it's essential to specify a behavior for
the case where both mechanisms are used, and I agree with both
of them that "xml:base wins" is the right answer.

Like Henry, I think it would be better to go ahead and 
discourage the use of smlif:baseURI beginning now, rather than
promising that we'll begin to discourage it later.  I'm not sure
how much importance I assign to it, though (that is, I don't know
whether I'll lie down in the road with Henry, or leave
him to hold the road down by himself on this one).

Comment 9 Pratul Dublish 2008-07-24 19:13:22 UTC
Additional resolution on 7/24 call

Consumer must support must at least one smlif:baseURI and xml:base. 
 The smlif:baseURI feature is supported in this version of this specification for compatibility reasons.  It is, however, deprecated and may be removed in a future version of this specification

Address 7b with the following
Compute from xml:base, if that fails, use smlif:baseURI (this applies to a consumer that supports both baseURI and xml:base)
Comment 10 Henry S. Thompson 2008-07-25 10:38:55 UTC
I am satisfied with the proposed resolution as amended
Comment 11 Virginia Smith 2008-08-15 20:24:09 UTC
Fixed SML spec only. Section 4.3.1, bullet 2 is rewritten (with Sandy's help). See that section for the new text.

SML-IF still to be fixed so this is still editorial.
Comment 12 Virginia Smith 2008-08-21 17:48:22 UTC
Latest proposal for SML-IF spec:
Comment 13 Kumar Pandit 2008-08-28 18:24:43 UTC
<johnarwe_> we had a draft last night.  ginny responded with a request to add:
            If an SML-IF consumer supports both mechanisms and the interchange
            model document it is consuming contains markup for both
            mechanisms, then the SML-IF consumer MUST use the xml:base
            mechanism to compute all [base URI] properties in the model

resolution on 8/28: the draft sent by John with the above sentence added is approved as the fix for 5542.                                   
Comment 14 Kumar Pandit 2008-08-28 18:34:07 UTC
additional resolution on 8/28: remove needsReview
Comment 15 Virginia Smith 2008-08-29 17:19:40 UTC
Fixed per comment #13, removed 'needsReview' per comment #14.

See diff at:

Changes are in sections 4.5, 5.3.2 - 5.3.4, 6.1.

Also, the 2nd note in 5.3.2 is changed slightly from the proposal. The 2nd paragraph now reads:

"Consistency checking of base URI results by SML-IF consumers is made optional to avoid requiring the potential overhead of performing twice as many calculations per relative reference as is minimally required to consume the model. An SML-IF consumer might choose to check base URI mechanism consistency based on input parameters, always, never, or based on any other criteria it chooses. <change>If both base URI mechanisms are used in a given interchange model document contained within a conforming SML-IF document, and a consumer understands both mechanisms, such a consumer must use the xml:base mechanism to compute the [base URI] property. This consumer may choose to ignore the smlif:baseURI information or it may choose to verify that consistent results are obtained from both mechanisms.</change> If both base URI mechanisms are used in a given interchange model document contained within a non-conforming SML-IF document, SML-IF provides no guarantees about the consistency of any [base URI] property computed using both mechanisms."
Comment 16 John Arwe 2008-11-06 00:45:54 UTC
The XML Schema WG endorsed this bug in (see also ).

I am contacting Schema's chair again today to solicit their formal feedback once again.  I am also leaving the keywords alone, because (a) the original submitter ...Henry... did in fact say here he was satisfied (b) the SML wg appears to have met the spirit of the URI issue raised in the endorsement above that was split off into this bug.