W3C home > Mailing lists > Public > www-tag@w3.org > February 2002

Packaging (was namespaces and MIME types)

From: Norman Walsh <Norman.Walsh@Sun.COM>
Date: Wed, 06 Feb 2002 16:51:22 -0500
To: www-tag@w3.org
Message-ID: <87665a46ud.fsf@nwalsh.com>
There's been a lot of discussion here about MIME types, the namespaces
of root elements, context, processing expectations, and the meaning(s)
of globally unique names. As I've tried to synthesize the discussion,
the following ideas have occurred to me.

One of the use cases we've been thinking about seems to be, "what can
you infer from an XML document if I don't tell you anything about it?"
What does this document mean?

<x:html xmlns:x="http://www.w3.org/1999/xhtml"
        xmlns:t="http://www.w3.org/1999/XSL/Transform"
        t:version="1.0">
  <x:body>
    <element xmlns="http://www.w3.org/1999/XSL/Transform"
             name="svg" namespace="http://www.w3.org/2000/svg">
      <attribute name="width">
        <value-of select="100 * 2"/>
        <text>px</text>
      </attribute>
      <attribute name="height">
        <value-of select="100 * 3"/>
        <text>px</text>
      </attribute>
      <element name="polygon" namespace="http://www.w3.org/2000/svg">
	<attribute name="style">fill:none;stroke:black</attribute>
	<attribute name="points">19,515 687,515 687,31 19,515</attribute>
      </element>
    </element>
  </x:body>
</x:html>

I think the answer is, "you can't tell." On the one hand, it purports
to be XHTML. But it also claims to be a stylesheet. And there's even
some SVG in there, albeit deeply hidden within the XSL transformation.

If I don't tell you anything else, the best you can hope to do is
apply some sort of heuristic. And I think I'm happy with that answer
as long as there *is* some way for me to tell you what it is.

One possible way for me to tell you is with the MIME type. But it
turns out, I think, that MIME types don't provide rich enough metadata
for me to tell you enough information.

(There's a related issue about whether or not you are somehow bound by
what I tell you, or by the context in which I tell you. I think the
answer to that question is "no". If I tell you something is a purchase
order and you want to harvest XLinks out of it, be my guest.)

When I've constructed complex XML documents involving several
namespaces, they've rarely been individual documents that stand by
themselves. Usually they're components of a larger system that
involves several documents (schemas, stylesheets, external images,
etc.)

I wonder, therefore, if it's reasonable to consider this problem in
the context of packaging. What I really want to hand you is my stuff,
plus some manifest that tells you what to do or at least where to
start. (Thanks to Chris Lilley for helping me see this.)

It seems to me that by making this a packaging issue we could make the
whole problem much more tractable. The packaging spec could describe
some basic sorts of metadata ("start here", "start with XSLT", "use
this processing pipeline", "apply this CSS to the result"), but it
could be extensible so that individuals and communities could devise
their own.

                                        Be seeing you,
                                          norm

-- 
Norman.Walsh@Sun.COM   | Any bureaucracy reorganized to enhance
XML Standards Engineer | efficiency is indistinguishable from its
XML Technology Center  | predecessor.
Sun Microsystems, Inc. | 
Received on Wednesday, 6 February 2002 16:53:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:04 GMT