Re: xmllink-970406 various

Michael writes:
| 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.

I suppose that applications apple.

| >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?

I have tried (not too hard) to envision what it might look
like in a same application, and haven't succeeded.  I think
the combination of ilinks and instance isn't enough information
for an application to apple up a display of the combination.

| (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?

At the time I argued that position I thought that the SGML ERB
was going to specify something about applications (as XML apps
are mentions in XML-lang).  By now we have established that it
will not.  So I will have to state my policy outside of XML, in
the larger architecture of the app, whatever it is, and having
these (probably inadequate) hooks in XML is only going to confuse

| >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.

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 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
| up.
| I hope this is helpful.

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?

  Terry Allen    Electronic Publishing Consultant    tallen[at]
    Davenport and DocBook:
          T.A. at Passage Systems:  terry.allen[at] 

Received on Tuesday, 8 April 1997 15:02:45 UTC