This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=4688 removed smlif:baseURI in favor of xml:base. The spec changes however went beyond what I think the work group agreed to. smlif spec xml:base in "2.2 Inter-document References" says "Although the example above defines the xml:base attribute on the document element, the xml:base attribute may also be defined on other element information items." This is different than the proposal we accepted as I understood it (the example shows what we discussed, but the second clause in the text goes further). What we discussed was literally just changing smlif:baseURI to xml:base everywhere, which means the relative URI text would read that /model/identity@xml:base would be used as the base URI value for all relative references. Implicitly this means that a model has a single base URI. If anyone believes that SMLIF inter-document reference resolution needs to allow xml:base's value in other contexts as described in the xmlbase spec, that should be a separate discussion since this would introduce for the first time the possibility of multiple base URIs in the same SMLIF document and the processing to compute the base URI for any given instance document would be more complex. Proposal: Change the spec to say that xml:base on the model (only) will be used for SMLIF inter-document reference resolution as the base URI for relative references.
Had extensive discussion around this issue during 2007-10-16 F2F meeting, under bug 5171. http://lists.w3.org/Archives/Public/public-sml/2007Oct/att-0114/f2f_10162007_minutes.html#item01 Considering that - Relative URIs in different model documents may want different base URIs - Supporting xml:base and [base URI] infoset property is not mandatory for all URI usages. - We want to minimize cases where we have to modify packaged documents. I propose: - Abandon xml:base and [base URI] - Add a <primaryAlias> to each document/docInfo/aliases. It acts as an alias, and it also provides the base URI for resolving relative URIs appearing in that document. - Either we require <primaryAlias>, or we say "base URI" is impl-dependent if <primaryAlias> is not specified. (Or there could be an IF-wide default base, similar to what we had before for baseURI, but not sure how useful it is.)
Example1: schemaLocation: http://example.org/abc/A.xsd with <include schemaLocation="X.xsd"/> http://example.org/abc/X.xsd http://example.org/xyz/B.xsd with <include schemaLocation="X.xsd"/> http://example.org/xyz/X.xsd The relative reference "X.xsd" in A.xsd is resolved using http://example.org/abc/A.xsd as the base URI, resulting http://example.org/abc/X.xsd. Similarly, "X.xsd" in B.xsd is resolved to http://example.org/xyz/X.xsd. Example2: SML references http://example.org/university/2006/Students.xml http://example.org/university/2006/Courses.xml http://example.org/university/2007/Students.xml http://example.org/university/2007/Courses.xml 2006/Students.xml has <course> <sml:uri>Courses.xml#course_100</sml:uri> </course> where the value of <sml:uri> is should be resolved to the absolute URI http://example.org/university/2006/Courses.xml#course_100 And 2007/Students.xml has <course> <sml:uri>Courses.xml#course_999</sml:uri> </course> where the value of <sml:uri> is should be resolved to the absolute URI http://example.org/university/2007/Courses.xml#course_999 In both of the above cases, having a single base URI will result in unexpected behavior (loading the wrong schema document or finding the wrong Courses.xml file).
*** Bug 5171 has been marked as a duplicate of this bug. ***
Proposal: 1. Define SML-IF document-wide baseURI. It must be an absolute URI. Its use is optional. It is semantically equivalent to the baseURI defined in the member submission specification. 2. Each document can define an optional primary alias among the set of aliases for that document. This can be a relative or an absolute URI. It serves 2 purposes: a. It acts as any other document alias. b. It participates in resolution of relative URIs as defined below. 3. Resolving relative URIs: a. If both baseURI and primaryAlias are missing ==> SML-IF file is invalid. b. If baseURI is missing, combine primaryAlias with relative URI to get absolute URI. primaryAlias must be absolute in this case. c. If primaryAlias is missing, combine baseURI with relative URI to get absolute URI. d. If both baseURI and primaryAlias are present, combine baseURI with primaryAlias and relative URI to get absolute URI 4. Remove the requirement in the SML-IF spec that document alias must be absolute URI. Advantages: 1. If no primaryAlias is present in an SML-IF file, its behavior is similar to what was defined in the member submission. 2. primaryAlias can be used to support scenarios where a relative URI must be resolved relative to the location of the containing document. This addresses the scenarios described in comment #2.
+1 for proposal in comment #4 One question for the case described in bullet d. : d. If both baseURI and primaryAlias are present, combine baseURI with primaryAlias and relative URI to get absolute URI Question:When both baseURI and primaryAlias are present, is it allowed for the primaryAlias to be an absolute URI ? I would incline to say yes; in which case, bullet d should be updated to cover this scenario : d. If both baseURI and primaryAlias are present i. if primaryAlias is a relative URI then combine baseURI with primaryAlias and relative URI to get absolute URI ii. otherwise ignore the baseURI and use only the primaryAlias to create the absolute URI for a relative URI
Please include the following in the fix Kumar: when for bullet 3.d, when the primary alias is absolute, then the IF baseURI is ignored. <Sandy> Sandy: would help to have a conceptual alias, which is always absolute. if the syntax to specify an alias is relative, then it is absolutized using the IF-wide baseURI. <Sandy> ... then whenever we talk about "alias", it's always absolute.
See below details on applied changes. Open attached documents to diff against the Jan 15 spec version Sandy, please check if I captured your request under comment #6 (..would help to have a conceptual alias..); more likely not covered since I wasn't able to completely parse the request :) If this is not covered can you please add more information on what exactly you want to see added to the spec Updated smlif.xsd and SML-IF spec : 1. smlif spec Created 3 new sections under 5.3.2 Document aliases - 5.3.2.1 smlif:baseURI - 5.3.2.2 smlif:primaryAlias - 5.3.2.3 Document alias processing http://dev.w3.org/cvsweb/~checkout~/2007/xml/sml/build/sml-if.html?content-type=text/html;%20charset=utf-8#Document_aliases I have updated a few other sections; see attached docs for a diff ( doc and html ). Created against the Jan 15 spec content. 2. smlif.xsd Created a new element, baseURI as a child of the identity element: <xs:complexType name="identityType"> <xs:sequence> <xs:element name="name" type="smlif:uriType"/> <xs:element name="version" type="smlif:tokenType" minOccurs="0"/> <xs:element name="displayName" type="smlif:displayType" minOccurs="0"/> <xs:element name="description" type="smlif:displayType" minOccurs="0"/> >>>> <xs:element name="baseURI" type="smlif:uriType" minOccurs="0" maxOccurs="1"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> Added a new type for alias and defined an optional primaryAlias attribute <xs:complexType name="aliasType"> <xs:complexContent> <xs:extension base="smlif:uriType"> <xs:attribute name="primaryAlias" type="xs:boolean" use="optional"/> </xs:extension> </xs:complexContent> </xs:complexType> Aliases type updated to refer to this new type: <xs:element name="aliases" type="smlif:aliasCollectionType"/> <xs:complexType name="aliasCollectionType"> <xs:sequence> <xs:element name="alias" type="smlif:aliasType" maxOccurs="unbounded"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType>
Created attachment 508 [details] diff version, html format
Created attachment 509 [details] diff version, doc format
Created attachment 513 [details] diff document - primaryAlias defined as a new element Based on review from group members, the current content has been updated to define the primary alias as a new child element of the aliases element. It was initially implemented by defining an optional primaryAlias attribute on the alias element. For clarity, attached document shows spec differences starting with the version when the base uri was defined using xml:base
Created attachment 514 [details] doc version of the diff document attached in comment #10
correction for comment #11 : The document attached on comment #11 is the html version ( and not doc version ) of the document described in comments #10
In section 5.3.2, I'm not sure what "suggested alternative" means? Who is this suggestion for: producer? consumer? I believe this should be normative so shouldn't the spec specify the alternative?
re comment #13 Section 5.3.2, the paragraphs describing the two base URI levels is meant to be informative ( non normative ). The intention for this sub-section was to suggest to an SML-IF producer scenarios for using the model/identity/baseURI, the document/aliases/primaryAlias, or both, when defining base URI for relative references. This section is part of a normative section and I agree with you that this is confusing. Proposed fix ( available on the editor's copy as well ) : http://dev.w3.org/cvsweb/~checkout~/2007/xml/sml/build/sml-if.html?content-type=text/html;%20charset=utf-8#baseURILevels Define a new non-normative section to contain the base URI level information. I have created this section : 5.3.2.1 Base URI Informal Description (Non-Normative) This specification defines two levels of base URI values to be used by relative URI references defined in documents in the interchange set: 1. A base URI value scoped to the interchange set, the interchange set level base URI, which is the value of the /model/identify/baseURI element. 2. A base URI value scoped to a single model document (definition or instance) level, the document level base URI, which is the value of the */docInfo/aliases/primaryAlias element. SML-IF producers have several combinations to consider when defining base URIs in an SML-IF document: 1. When the interchange set contains no relative URI references subject to SML-IF URI processing (see 5.3.3 URI Reference Processing), both levels may be omitted. 2. When relative URI references subject to SML-IF URI processing exist in the interchange set and all have the same base URI value, the interchange set level is the suggested alternative. 3. When relative URI references subject to SML-IF URI processing exists in the interchange set and all have different base URI values, the document level is the suggested alternative. 4. When relative URI references subject to SML-IF URI processing exist in the interchange set and they use a mixture of base URI values, some the same and some different, both levels may be used.
Created attachment 518 [details] Word doc diff version for changes described in comment #14
section 5.3.2 says: If a document in the interchange set contains a relative URI reference subject to SML-IF URI processing, then it MUST NOT have a value for its {base URI} property. This is not correct. it should say MUST instead of MUST NOT. even then, the definition is not complete since baseUri may be empty if all docs having relative refs have an absolute primary-alias.
Re: comment #16 > it should say MUST instead of MUST NOT Agree. > definition is not complete since baseUri may be empty if all docs having > relative refs have an absolute primary-alias. The value of {base URI} comes from either the baseURI element, or the primaryAlias element, or a combination of them (section 5.3.2 under {base URI}).
addressing comment #16 Replaced MUST NOT with MUST; good catch.. :) >>>If a document in the interchange set contains a relative URI reference subject to SML-IF URI processing, then it **MUST** have a value for its {base URI} property. I agree with Sandy's comments on the incomplete definition issue ( under comment #17 ); so this part does not have to be addressed
(from editor's draft) from: the actual value of /model/identify/baseURI, primaryAlias or alias to : the actual value of /model/identity/baseURI, primaryAlias or alias = the rest looks fine. Glad Kumar caught the must/not, ouch that would have left a mark.
addressed comment #19
In general +1 for the changes, with the following notes (based on the Word doc diff version comment #14): 1. There needs to be a global change from "/model/identify" to "/model/identity". 2. In section 5.3.2, "{aliases}" is defined as a set of absolute URIs but primaryAliases can be relative references. Isn't this an inconsistency? 3. Numbered items 3 & 4 in 5.3.2.1 seem poorly expressed: 3. When relative URI references subject to SML-IF URI processing exists in the interchange set and all have different base URI values [if "all" refers to each, why can't two references share the same base URI value?], the document level is the suggested alternative. 4. When relative URI references subject to SML-IF URI processing exist in the interchange set and they use a mixture of base URI values, some the same and some different, both levels may be used. [I would suggest removing the phras "some the same and some different"] SUGGESTED REVISION 3. When relative URI references subject to SML-IF URI processing exists in the interchange set and each document has its own base URI value, the document level is the suggested alternative. 4. When relative URI references subject to SML-IF URI processing exist in the interchange set and they use a mixture of base URI values with some documents sharing the same value, both levels may be used.
+1 for the resultant text in the current editors' draft, except for the following: [1] A part of the example in 4.2 still uses the old style primaryAlias attribute. <alias primaryAlias="true">/SFU/Courses.xml</alias> [2] The following change required at many places. /model/identify ==> /model/identity Comment# 21 made the same suggestion. Repeating it here for the sake of completeness. [3] I agree with the suggested revisions from Kirk in comment# 21 about rephrasing of #3 & #4 in 5.3.2.1.
addressed [1] and [2] from comment #22 Comment [3], including Kirk's suggestions on comment #21, will be addressed by a new proposal, to be attached to the defect once there is agreement within the editors that this is the preferred content. Ginny is driving this work
addressed comments #21 and #22 Updates: The content of section 5.3.2 Document Aliases have been updated ( the content is refactored in such a way that it's easier to just look at the new content; a diff doesn't help that much so I am not attaching one) See below the link to the updated content. Section 5.3.2 was split in 5.3.2 Base URIs and 5.3.3 Document Aliases so the review should include these two sections: http://dev.w3.org/cvsweb/~checkout~/2007/xml/sml/build/sml-if.html?content-type=text/html;%20charset=utf-8#Base_URIS
Resolution is to mark fixed. Kirk to enter notational issue as a new bug for CR.