Re: Comments on the architecture doc

> Consider, let's say, a CSS stylesheet (a very simple form of processing
> specification) associated with the namespace XHTML. Now consider the
> following document (which I assert is XSLT, not XHTML) and how reliably
> the CSS would apply to the data:

If it is XSLT, what's the problem with wrapping it with an XSLT
container, or with delivering it as application/xslt+xml?  Why
insist (if I understand your position) that it be able to be
delivered as application/xml *and* still be processed as XSLT?

[example snipped]

> I could produce examples like this all day. The most extreme example is
> just:
> 
> <foo:bar>
>   <html:....>
> 
>   </html:...>
> </foo:bar>
> 
> For all you know, foo:bar means: "please ignore everything in here." So
> the right processing specification is none at all. This is completely
> legal according to all existing W3C specifications and (AFAIK)
> guidelines.

That's my point too.  The parent container(s) define the meaning of
containment.  In this context, those containers are, in order; media
type, root namespace, other nested namespaces.

In other words, the media type determines the way in which the root
namespace is interpreted.  application/xml doesn't define that meaning.
But that doesn't prevent us from defining another media type that is
unambiguous about how root namespaces are used to trigger processors.

My soon-to-be I-D on this topic is;

http://www.markbaker.ca/2002/01/draft-baker-generic-xmlns-dispatch

Some parts are stable, but the core rules are a work in progress.  I'm
currently going through the various cases of how schema rules (XML
Schema wildcarding) interacts with mandatory extension declarations such
as SMIL's "skip-content" (which, though not commonly used in other
languages, should be more widespread and so I believe worthy of
consideration now).

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@planetfred.com
http://www.markbaker.ca   http://www.planetfred.com

Received on Sunday, 3 February 2002 23:03:16 UTC