RE: Namespace dispatching

 Micah,
 I see your point. I think the right balance could be achieved by
saying on the sender: "We expect the XHTML processor to be able
to handle XInclude and therefore this thing is an XHTML document
all right." And if the XHTML processor handles XInclude by 
processing that first and separately (by being run after an 
XInclude processor), that's an implementation choice. 8-)
 Of course we are getting to matters of taste so where in one
case the wrapper element is not needed (as above), in other cases
the wrapper element is preferable, and I think every spec that
can be handled independently should provide such a wrapper
element to be used "where appropriate" to mark the document's
type.
 Best regards,

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)
                   http://www.systinet.com/



On Wed, 20 Feb 2002, Micah Dubinko wrote:

 > 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 03:03:17 UTC