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

RE: Namespace dispatching

From: Micah Dubinko <MDubinko@cardiff.com>
Date: Wed, 20 Feb 2002 21:07:39 -0800
Message-ID: <E840F0B7E6189547BDB91DA8BF2228AB28C275@csmail.cardiff.com>
To: "'www-tag@w3.org'" <www-tag@w3.org>
Cc: "'jacek@systinet.com'" <jacek@systinet.com>
Jacek Kopecky <jacek@systinet.com> wrote:
...
 b) if we expect that there will be a special XInclude processor 
preceding the XHTML processor, the document should be wrapped in 
an element like xincl:includer. This element would be removed 
(its contents being moved up one level) after processing by the 
XInclude processor. 
...

Speaking of wrapper elements, why not just do this:

[Warning: exaggeration for the sake of making a point follows]

<xml:Envelope>
 <xml:Header>
  <xml:ProcessingStep process="http://www.w3.org/2002/xincluder"/>
  <xml:ProcessingStep process="http://www.w3.org/2002/xhtml/render">
   <xml:ProcessingStep process="http:/www.w3.org/2002/svg/render"/>
  </xml:ProcessingStep>
 </xml:Header>
 <xml:Body>
  <html xmlns="http://www.w3.org/1999/xhtml">
    ...
 </xml:Body>
</xml:Envelope>

This highlights the tension between the strictness of total self-description
vs. a more flexible (and therefore less self-describing) set of constraints.


Obviously, this would never work as presented. But it's interesting to ask
"why not?" If you take out or make palatable the unworkable parts, does the
remaining shell contain anything useful we can take to the bank?

Additionally, many of unpalatable aspects of such a design (such as effects
on existing implementations) also apply to concepts like <xincl:includer>
wrapper elements.

What's the right balance?

.micah
Received on Thursday, 21 February 2002 00:10:57 GMT

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