- From: C. M. Sperberg-McQueen <cmsmcq@acm.org>
- Date: Wed, 1 Aug 2007 15:48:03 -0600
- To: public-sml@w3.org
- Cc: "C. M. Sperberg-McQueen" <cmsmcq@acm.org>
Some time ago (an embarrassingly long time ago, to be more specific) I took an action (ACTION-94, if you're keeping score) to try to start an email discussion thread around issue 4636, which asks what SML section 3.3.1.1 ought to say about fragment identifiers. This is my attempt to discharge that action. Some of what follows is copied from the original description of the issue; some is elaboration. Section 3.2.1.1, "Fragment Identifier" (it was 3.3.1.1 in the submission text of SML), specifies that when the URI reference method is used, fragment identifiers must use the xmlns() and xpointer() schemes defined within the XPointer framework. At the face to face meeting in Redmond (June 2007), some WG members suggested that the SML spec really shouldn't talk about that level of detail, and that 3.3.1.1 should be deleted. The rules governing URIs are defined by other specs: anything we say will either just repeat what they say, which would make it unnecessary, or else constradict what they say, which would make it problematic. Either way, we lose. Others felt that the requirement should be retained, if not necessarily in its current form, and that logical completeness in the description of the URI spec demands that we have SOMETHING to say about fragment identifiers. Web architecture says that fragment identifiers depend on MIME types -- what MIME types do the documents in an SML model have? Details TBD, but since they're all XML documents we can assume most will be application/xml or some specialized MIME type which follows the convention of using "+xml" as the suffix of the MIME type, to indicate that data with that MIME type will be in XML. (An example is the SVG MIME type, "image/svg+xml".) Several questions seem to be deeply intertwined here: 1 Should we say anything at all about fragment identifiers? In the interests of starting discussion, I'll play devil's advocate here. No, we should not say anything at all about fragment identifiers that are legal in the URI scheme. We should say that the content of sml:URI should be an IRI (or a URI, but that's a separate issue already under discussion), as defined by the current RFC or its successor, and leave it at that. Or we can say it's got to be a value of type xsd:anyURI. If SML references are guaranteed to be references to XML documents, then we know, and consumers will know, that fragment identifiers will be those defined for XML data. (If we care about this topic, then we may wish to help push the revision of the relevant RFC along. It needs revision and currnetly it's stuck.) 2 Should we specify that fragment identifiers should fit within the XPath framework? We can recommend it; we should not require it of conforming data, since strictly speaking the definition of what's legal in a URI or IRI is outside our job description. 3 Should we require that all SML processors who support the URI reference method [scheme] must support some specific set of fragment identifier schemes? We can and should require that consumers be able to handle fragment identifiers in specified schemes within the XPath framework. But the xpointer() scheme is not a good choice: we should require xpath1() or xpath2(). The SML submission does this by requiring that xmlns() and xpointer() be supported. I think it's useful to require that any software claiming to support the URI scheme in a conformant way must support specific schemes. It's true that processors aren't required to support the URI scheme in the first place; but we can make the claim "this processor supports the URI scheme" be more meaningful, if we say a bit more about what it entails, by setting a floor. 4 Should we require that all SML data which use the URI reference method [scheme] must formulate their fragment identifiers using some specific set of fragment identifier schemes? In other words, what is the ceiling which limits what schemes may be used in SML data or supported by SML software? The submission does this, by requiring that xmlns() and xpointer() be used. We should NOT require this. We should allow any pointer scheme compatible with the relevant specs; in particular we should allow any schema compatible with the XPointer framework. 5 Assuming we say anything at all, what should be said in the SML spec and what should be said in the SML IF spec? There was some sentiment for putting most of the detail into the IF spec and saying just enough in SML to achieve logical completeness. Me, I'm not sure what belongs where. --Michael Sperberg-McQueen
Received on Wednesday, 1 August 2007 21:48:13 UTC