- From: Micah Dubinko <MDubinko@cardiff.com>
- Date: Wed, 20 Feb 2002 21:07:39 -0800
- 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 UTC