Re: xmllink-970406 various

On Tue, 8 Apr 1997 11:58:50 -0700 Terry Allen said:
>Michael writes:
>| >On another point, 5.1 opens with a carefully worded para about
>| >subordination of the XML spec to URL semantics for non-XML
>| >data types.  It's unclear what the upshot is, e.g., when an
>| >XML instance (I'm beginning to think that calling XML instances
>| >"documents" is hindering comprehension of architectural issues)
>| >uses a TEI-style URL to point into an HTML document.  It would
>| >be useful to provide somewhat more closure to this para.
>|
>| The URL specs indicate (at least, the ones I've looked at do) that
>| the semantics of a fragment identifier depend on the type of
>| resource of which it's a fragment.  So the semantics of
>|
>|    http://www.foo.org/bar#baz
>|
>| are defined by the XML spec if the object is application/xml, and
>| are defined by the HTML spec if the object is text/html.
>|
>| Perhaps this ought to be pointed out explicitly, but it's not our
>| call, it's built into the fabric of the relevant RFCs.
>
>Yes, I agree that's so, but do you expect XML TEI pointers into
>HTML documents to work?  or are they meant only for pointing into
>XML instances?  And if the TEI pointer is in a query instead
>of a fragment ID?

The URL specs require, as I understand it, that fragment identifiers in
the form of XML TEI pointers be used for pointing at XML documents.  In
that sense, they are clearly 'only for pointing into XML instances'.

If an HTML document is served as, or coerced into, MIME-type
application/xml, then for purposes of these RFCs it is an XML document,
and I would expect to assent to the following statement:

  Either XML-style pointers into this document work, or else
  the browser is broken (not handling XML pointers correctly) or
  else the document is broken (there is no element with id='A27')
  or else the pointer is erroneous (it should have been 'A72').

If the HTML document is served as text/html, then a fragment identifier
like "#id(a27)" will have the usual HTML meaning:  it will look for
an element <a name="id(a27)">.

If the TEI pointer is in a query instead of in a fragment ID, then
I believe the same rules apply as apply with any query:  if the
server understands the query (here:  if the server supports XML
queries and is running without errors), then the server will execute
the query and return the result.  If the server does not understand
the query (e.g. because it doesn't understand XML TEI queries), then
it won't perform the query and will probably return an error report.
(I don't know what the relevant RFCs say).

No server is required to support any particular query, right?  If
you ask for URL http://www.uic.edu/cmsmcq-bin/cgi.rexx?foo=bar&fu=baz
it's a legal URL.  There is even a CGI script which will answer you.
It won't do anything with the query, but then NO server will do anything
useful with a query unless it's a query it knows how to do something
useful with.

Before XML, the set of query languages guaranteed to be understood and
acted on properly by all servers was empty.

After XML, it will still be empty.

So the answer to your question "And if the TEI pointer is in a query
instead of a fragment ID?" is "The TEI pointer will work if the server
understands TEI pointers, thinks you are authorized to use them, and
is working without error.  Otherwise the TEI pointer won't work."
For 'TEI pointer' read 'query' and this becomes true of every query
syntax that now exists or ever can exist.

Since this is so obvious I find it painful to say it, I can't believe
I'm answering the question you really have in mind, though I'm
answering the only question I can find in your query.  Answer me
honestly, Terry:  is this a trick question?

>To rephrase, is this language applicable to XML only or to URLs
>occurring in any context (HTML, VRML, ETF) pointing into XML?
>Or does it apply to URLs generally?

It cannot apply to URLs generally because the defining RFCs say that it
cannot and does not.

It can and does apply to URLs in an HTML document pointing into an XML
document, because the defining RFCs say that it can and does.  Simple
example, as I understand things:

  1 in an HTML document, you embed a link pointing at an XML
document:

  See <a href="http://erewhon.com/utopia.xml#id(a42)">the Utopia
  server</a> for more details.

  2 I look at your HTML document using a common off-the-shelf browser
named &cots;, and I click on the link.

  3 The &cots; browser fetches the document and notices, from the
HTTP header, that the document is in a data type it doesn't know.
It checks its internal table of helper apps and either

    (a) asks you what to do with the document, because you don't
have a helper app specified for application/xml, OR

    (b) launches the XML browser of your choice (&Xboyc;) and tells
it "By the way, the user specified the fragment called "id(a42)"
-- just the way the XML browser might launch a JPEG viewer and say
"The user wants to see this particular rectangle".  The &Xboyc;
browser will then either find id(a42) or so infuriate you that you
delete it from your disk.  Natural selection will soon ensure that
xml browsers do The Right Thing when launched from &cots; browsers.

Since I don't really understand the nature of your confusion, I have
no idea whether I am clarifying matters for you or not.  If you are
asking Socratic questions intended to lead me to see the fundamental
error of my views, you aren't succeeding yet.

-C. M. Sperberg-McQueen

Received on Tuesday, 8 April 1997 19:24:52 UTC