- From: Norman Walsh <Norman.Walsh@Sun.COM>
- Date: Wed, 06 Feb 2002 16:51:22 -0500
- To: www-tag@w3.org
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 UTC