Re: Re Stylesheet association

At 9:13 AM -0800 3/14/97, Terry Allen wrote:
>Yes.  I'm not thinking about simply constructing a grove, but
>actually being able to use it (or even know what to do with it).

The "simple case" (as you refer to it below) will never go away. Web
crawlers, text indexers, web mappers, generic XML databases, and the like
will need to be able to pull in lage quantities of XML text, and my often
care _only_ about the syntacxtic structure of the XML -- leaving the
semantics out, or leaving them to another module.

For those cases, self-delimiting syntax, without required semantic
knowledge, is essential.

SOme applications will simply say "stuff your package: give me the
document" and for those applications, packaging is irrelevant to XML
syntax. So there is nothing to reconsider.

>So far as I understand what you're saying, such an arrangement
>would rely on the user already possessing some sofware that
>encapsulates the semantics of the XML.  Is that right?  If so,
>that software already has the information about what tags are

Not if we don't care about the semantics of the XML!

>| > I am more concerned about packaging and delivery in general than
>| > with <empty/>; I brought it up only to show that packaging and
>| > delivery have implications for aspects of XML that have already
>| > been decided - but could be reconsidered before everyone's feet
>| > are set in concrete.  Now's the time.

I agree that packaging and delivery are critical -- but I am not convinced
that they (should) have implications for the syntax.

>| Ok.  What implications?  I must be missing the point of this
>| in the mail avalanche.
>It has been argued that XML instances must stand on their own,
>hence the need for reserved attribute names; but when I look
>at how XML will have to be packaged and delivered in all but
>the simplest cases, it seems to me that there is always going
>to be something else, be it a catalog, a style sheet, etc.
>So design decisions made on the basis that XML instances must
>stand on their own may have been ill considered.

No, carefully considered. There are applications that don't care about
semantics in the senses that you mean...

>Now one can argue that the simple case must be accomodated,
>and that complexity is unwanted, hence complex cases must use
>the syntax invented for the simple cases (which is where we're
>at today).  If that point of view survives a serious consideration
>of packaging and delivery, okay; but let's consider.

I find the dependence between empty element declarations and DTDs
inconvenient even in regular SGML -- Looking at a document in an unfamiliar
DTD is a minefiled until one has internalized the element definitions -- so
I don't even regard the EMPTY suntax of XML as a "notorious wart" but
rather an "examplary improvement".

>[To throw another log on the fire:  if XML is delivered as
>MIME type "XML-version-number", or whatever the magic string
>will be, is there any need for a PI that says the same thing
>(XMLDecl, production 29)?  What's the need?]

Well, I would still argue strongly that the PI and the HTTP header should
be exactly equaivalent (as to syntax and semantics) and thus optional when
HTTP is in use. However, I lost that battle. And I do accept the argument
for in-document meta-data, since XML documents may move by other channels,
we need meta-information in the document as well as in the HTTP channel.

This does point out that the HTTP header should just be
text/XML or application/xml (MIME experts can decide between these -- I
once thought I understood it, but I don't think I really do). The version
number is _not_ needed since it will be in the document.

  -- David

David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________

Follow-Ups: References: