Re: Linking to stylesheets in XML

Lee wrote:
| > at everything you might want to point at, packaging it together, and
| > delivering it without ambiguity (avoiding the Panorama disease).
| 
| We prefer not to refer to Panorama as a disease, actually.
| I think this is a little excessive.

No, the disease is ad hoc semantics and lack of cooperation with
Intranet infrastructure, leading to what the pediatricians call
"failure to thrive."

| > http://www.wco.com/~books/draft.5feb97.txt
| 
| If that proposal were used for HTML, browsers like Netscape and Opera would
| be noticably slower.  I don't think anything that is demonstrably worse
| than current practice should be adopted, although it may be considered
| where it has merit.

Current practice for SGML (Pano) is frequent failure.  The proposal
is *not* for implementation, as it says quite clearly.  It could be
streamlined and optimized in many places, I'm sure.

| The SGML Open multipart-related draft was done so that SGML could be
| exchanged by e-mail.  It doesn't work well for the web because it
| precludes (or considerably conplicates) parallel fetching.

Email was one of the requirements but not the only one, and it is a 
requirement for XML that the user be able to receive the XML
instance and *later* do something with it, much the same situation.

Back on the point, If things are wrapped up together you don't need to fetch 
them in parallel.  And as the SO draft was never implemented, how can you
say it doesn't work?  In any event, the issue here is how to
identify the type of thing fetched and associate it with something
else, that is, semantics.  My proposal in its present form is intended
to smoke out all the needed semantics (see list below).  Is there something 
missing from it on that score?

| For example, once I have seen the start of an XML document, up to the
| end of the DOCTYPE section, I know whether I have to fetch a DTD, and,
| if so, how.  So I might as well start fetching it immediately without
| waiting for the rest of the document.  Same for style sheets (I hope).

And if you already have it because you received it in the same package
as the XML instance, you have it already at hand.  If the publisher
has provided a pointer to it instead of including it in the package,
how much worse off are you?  Read the proposal again; it attempts to
handle this issue.

| Since XML now has PUBLIC Identifiers, I will want to do my DNS queries
| on those (the resolution method I've chosen [1]) as soon as possible, since
| it can take several seconds.  So I want to get references to all included 
| files as soon as possible.
| 
| Hence, I want to get, in this order:
 a | * the start of the document
 b | * all external DTD fragments
 c | * URLs of any included images, so I can start fetching them
 d | * the text of the document

Yep, my proposal is intended to provide all this information.  Here
are the parts of the multipart/related message I think must be defined
for SGML (some can be pointers instead of full content):

MIMEMAP:  maps the MIME Content-IDs to URNs (giving you the bootstrap
info for URN resolution) and identifies their function in this scheme.  
Modified for XML, this is simply a list of the Content-IDs and
what function the parts have.  It points you to (a) and (d), which for
simple cases seem to me to be very much the same thing.

ROOT-SDECL:  the sdecl for the SGML entity in which parsing begins
   (unneeded for XML)

ROOT:  the SGML entity in which parsing begins (= XML instance) (a & d)

MD-META:  metadata for the Main Document (MD = XML instance, to simplify)

MD-INTPROP:  intellectual property information (not really needed, but
   I'll run it up the flagpole and see if the guys with a flag that
   shows a flag salute)

ALLENTS:  list of all text entities that compose the MD.  (d?)

STARTPARSE:  list of all entities needed to start parsing. (includes b)

ALLOPTS:  list of all optional entities (not needed to start parsing)
    (includes c)

So what's the overhead?  unpacking the MIME?  MIMEMAP points you
everything you want to know; you could even do partial unpacking
and get started quickly.

| With HTTP NG, this can all be done over a single HTTP connection, if
| everything comes from the same server.  With HTTP 1.1, I can fetch
| multiple things in sequence cheaply, so I can keep just a few connections
| and multiplex over them myself if I want in my client.

You are completely missing the point, which is that these things have
to be identified by function.  You could multiplex Pano today and it
would have the same problems with entityrc files (I refer to Pano 
because it's our running code, not because I expect it to be bug-free).

| None of this is to say that Terry's Unoptimized SGML-Bundle Relations Schema
| does not have merit for other uses, by the way, than for interactive Internet
| delivery of SGML.

That's the intended use, of course.  You've failed to make any
argument against it; you simply repeat that you like HTTP better
than MIME.



Regards,
  Terry Allen    Electronic Publishing Consultant    tallen[at]sonic.net
                   http://www.sonic.net/~tallen/
    Davenport and DocBook:  http://www.ora.com/davenport/index.html
          T.A. at Passage Systems:  terry.allen[at]passage.com

Received on Saturday, 19 April 1997 17:26:53 UTC