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

Re: Comments on the architecture doc

From: Paul Prescod <paul@prescod.net>
Date: Tue, 05 Feb 2002 01:30:00 -0500
Message-ID: <3C5F7BE8.53D803D8@prescod.net>
To: Tim Bray <tbray@textuality.com>
CC: www-tag@w3.org
Tim Bray wrote:
> 
>...
> 
> But namespaces can be used as labels to identify languages:
> examples are XHTML and SVG, and there are more every day.  This is
> the interesting case that we're arguing about.  When we've got a
> language that declares a namespace as part of its definition, a
> namespace on the root element is a plausible signaling mechanism.

"Is a root-level namespace equivalent to a document type?" Fine, I could
accept either answer to that question (though XSLT may have to change if
the answer is "yes").

But there is another idea that's been floating around that you can pick
out XHTML or SVG elements in SOAP or XSLT or WSDL or XML Schema or
whatever and process them using a generic XHTML or SVG processor (or
schema, or stylesheet, or ...). That doesn't work. First you need to
interpret the data (including the XHTML elements) *as* XSLT or WSDL or
XML Schema. Then the processor for that language needs to build a
document tree that conforms to the model anticipated by the
specifications for XHTML or SVG or whatever.

To put it another way, this:

<xsl:template match="..">
  <html:p>

  </html:p>
</xsl:template>

is just syntactic sugar for this:

<xsl:template match="..">
  <xsl:element name="html:p">

  </xsl:element>
</xsl:template>

So your processor may think it sees XHTML but it doesn't really. The
same goes for SOAP, WSDL and, I think, probably any environment where
one namespace embeds a second where the second was not designed
specifically to be embedded (which is almost always the case).

 Paul Prescod
Received on Tuesday, 5 February 2002 01:32:34 GMT

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