Re: [nsMediaType-3] Principles and corner cases

Tim Berners-Lee wrote:
> I propse that in fact we clean this up by looking at an SVG document
> with embedded XSLT as an SVG document.  

You can look at a pig as a bird but it won't fly. ;)

There are two specifications, in this case SVG and XSLT. One defines
completely the meaning of the document. You can apply an XSLT processor
reliably to it. You can apply an XSLT "schema" to it reliably. XSLT was
specifically designed to allow other namespaces to be mixed in
arbitrarily. To summarize, the document is in the set of octet-streams
predicted by and defined by the XSLT specification.

On the other hand you have SVG (or XSD, or XHTML, or...). Software
written for SVG will break when it sees a document with embedded XSLT.
SVG schemas/DTDs will break. The document is quite likely not in the set
of documents described by the SVG specification. Consider what a browser
will do when it sees this:

  <xsl:if ....>

(simplified syntax for clarity)

> To do anything else leads, as far as I can see, to total chaos.
> The supreme court will have to sit every time we need to figure
> out whether it is an SVG, XSLT, or Conditional document.

No, there is no chaos. The following characters represent bytes. What's
the media type:

[208, 207, 17, 224, 161, 177, 26, 225, 0, ...]

Turns out it's a word doc. But I only knew that through metadata. So
that's one strategy. Another strategy is to make documents
self-describing. So you can know this thing is text/xslt because
somebody told you.

<?xml-doctype type="text/xslt"?>

You could argue that we should just use namespaces for this but for the
last two years we've told people that namespaces do NOT serve as
document types or serve any other semantic function. They just globally
uniqify names. Now we want to change the rules and XSLT will break.

 Paul Prescod

Received on Sunday, 3 February 2002 20:58:14 UTC