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