RE: bug 5542 - new option 4 to consider

Regarding “   5. Support for xml:base is optional for smlif consumers” – this is true insofar as smlif consumers are not required to support any specific part of the spec based on their own use of the smlif document. However, the statement “In particular, if a conforming SML-IF Consumer performs interchange model validation<http://dev.w3.org/cvsweb/%7Echeckout%7E/2007/xml/sml/build/sml-if.html?content-type=text/html;%20charset=utf-8#interchange_validation>, then that process MUST be performed as described in this specification.” My interpretation of this statement is that, if a consumer performs model validation, then it must support all parts of the spec, such as aliases, etc… and xml:base should be included in that requirement. This would support interoperability. In other words, consumers performing model validation are required to support xml:base (but not smlif:baseURI).

In addition, I think a statement in the spec to the effect that smlif:baseURI will be deprecated would be appropriate and provide clear guidance to the SML community of the future direction of the spec.

--
ginny

From: public-sml-request@w3.org [mailto:public-sml-request@w3.org] On Behalf Of John Arwe
Sent: Wednesday, July 09, 2008 9:08 AM
To: public-sml@w3.org
Subject: bug 5542 - new option 4 to consider


Regrettably I will not be around for the rest of the discussion, but our inability thus far to arrive at consensus on URI absolutization has been much on my mind.  As we discussed at the face to face, absent some movement or new option we appear to be faced with a situation where either alternative results in an objection.  In thinking through the issues again (and again... :-) ) I arrived at another alternative different enough from the three we outlined in Edinburgh that I'm going to offer it up even though I will be out for a while.

I heard two separate reasons against the change requested now in 5542, from smlif:base to xml:base:
A. existing documents use smlif:baseURI, and would be rendered automatically invalid
B. neither existing reference implementations supports xml:base.

Getting a clean separation of these issues actually yields some benefit I think, leading to the following as an option.  Not all parts are changes, some are re-statements of current spec contents simply for clarity about the final end state in the spec.

   1. Allow smlif:baseURI (optional) in the model element (and only there)
  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

Net result: A conforming SMLIF consumer may process xml:base (if it supports each element)  ... not must, according to the definition in the spec.   In other words, since support for xml:base is optional in the document, conforming consumers don’t have to process xml:base in an IF document containing it, but an IF document containing xml:base is still conforming.  The preceding is equally true of smlif:baseURI.  The working group would need to decide how consumers that understand both smlif:baseURI and xml:base behave when both are present in a document (presumably, xml:base "wins", but more complex answers could certainly be constructed).

Part 1 addresses reason A directly.  It makes smlif documents containing smlif:baseuri at the model level (the only kind I heard asserted to exist) conforming.
If definitive evidence emerges that existing documents also use doc-level base URIs, I think we could extend this to cover doc-level as well, it just makes the story more complicated.

Now to address reason B, changes to existing reference implementations.

Part 4 means that a conforming SML-IF producer MUST be ABLE to generate an IF document using xml:base – similar to the requirement for reference conformity and sml:uri, it could require addition of a run-time parameter to do so.  By allowing existing consumers to remain unchanged, the burden is reduced vs some other alternatives. It's now a matter of whether or not reference implementation owners choose to update their producer implementations, a decision that can be made by each owner.  As I read the definitions, this allows existing reference implementations to be fully compliant by just adding a "spit out xml:base instead of smlif:baseURI" option on their producers.  The producers may or may not use that option themselves during ordinary processing so it need not be disruptive to exploiters, and they have an orderly migration path under their own control should they wish to use it.  There is no requirement for a conforming consumer to process documents containing xml:base that I can find in the spec, since xml:base is optional.

From the discussions to date, I would be cautiously optimistic that the W3C will be willing to tolerate this "less whole-hearted" endorsement of xml:base as a practical compromise based on the wish to not obsolete existing documents.

This option appears to be less disruptive and/or burdensome to existing reference implementations than several of the other options already articulated, while simultaneously addressing the conformance of previously existing documents and the W3C's wish to encourage consistent solutions to generic problems once those solutions have been endorsed by the Web community.  If the working group were able to achieve consensus on this, one roadblock to proceeding toward Rec status would likely be removed.

Best Regards, John

Street address: 2455 South Road, P328 Poughkeepsie, NY USA 12601
Voice: 1+845-435-9470      Fax: 1+845-432-9787