issue 4636 What should SML 3.3.1.1 say about fragment identifiers?

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