Re: xmllink-970406 various
On Sun, 6 Apr 1997 19:44:15 -0400 Terry Allen said:
... a number of useful things.
>As the document has today's date I take it this is a new version;
>if not, and if these issues have been dealt with, please ignore.
Since I suspect that Tim and Steve and Jon are seeking their
well-deserved rest, preparatory to the Web conference -- or are
in transit -- I'll try to answer at least some of these.
>[Forshadowing: the last para of the section speaks of the values
>of (all) attributes being used in "processing the locator element",
>yet these attributes seem to apply not to processors but to applications.]
Good point. We need a nice verb for what applications do. Normally
I'd say 'process' but our distinction between the 'XML processor'
and the 'application' makes that untenable. I'm pretty sure that
these attributes and their information are intended for exploitation
by apps, not XML processors per se.
>It is stated that if the Locator element doesn't specify a value,
>the value is inherited from the Extended element. It is not stated
>whether the value of a Locator element attribute overrides that
>of an Extended element attribute. I gather that is the intent; if
>so, please say this explicitly.
I for one understood that to be the intent.
>However, for these three attributes it's unclear what various
>combinations would mean. If an Extended has three Locators,
>and the Show attribute on the Locators is Embed for one,
>Replace for another, and New for the third, what should an
>ordinary browser app do?
I would say "If the user tries to actuate the link starting at
the first location, then embed; on actuation of the link
starting at the second location, then replace, etc." Is there
really any other possible interpretation?
(There is, to be sure, a certain uncertainty about what can be
meant with Embed and Replace on extended links with, say, ten
locators. To be addressed later ...)
>I suggest that as the SGML ERB is unwilling to specify anything
>about applications, these attributes be stricken and the issues
>they are meant to address be dealt with later. Better to leave
>them out than underspecify them.
Whoa! I thought you were the one saying that as a publisher
you ABSOLUTELY REQUIRED the ability to state your policy that
a given legal notice, conveyed in a link, was to be embedded
automatically in the text before display to the user. It seems
to me that these attributes are a reasonable attempt to give you
what I thought you said you needed. What gives? Did I misunderstand
you that badly?
>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
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.
>The second para speaks of describing query syntax and semantics
>for URLs that point to XML. Is it intended to be binding on, e.g.,
>HTML docs that use queries to point into XML instances? If
>so, how, exactly?
Er, in the sense that if your browser doesn't know what to do with
XML documents, it won't know what to do with XML-link fragment
identifiers, and it needs to call a helper app that knows what's
I hope this is helpful.
-C. M. Sperberg-McQueen