RE: Namespace dispatching

 Julian, 
 same way:
 a) if we expect that every XHTML processor will handle XInclude, 
it's easily an XHTML document and no change need be done.
 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. 
 
 There may be practical problems with nesting the tools
(XInclude, XSLT, encryptions etc. come to mind) but I think these
practical problems would ultimately be the result of the complex 
design of the particular application.
 I have a feeling deep inside that there may be a situation where 
you would not, in fact, be able to keep the root element 
indicating the current type of the document in a complex set of 
transformations (XInclude processing is also a transformation), 
but I cannot think of a concrete example.
 Until I see such a case where the approach of mandating that the 
root identifies the document breaks things considerably, I'll 
keep supporting the approach.

                   Jacek Kopecky

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



On Wed, 20 Feb 2002, Julian Reschke wrote:

 > > From: www-tag-request@w3.org [mailto:www-tag-request@w3.org]On Behalf Of
 > > Jacek Kopecky
 > > Sent: Wednesday, February 20, 2002 9:05 PM
 > > To: Paul Prescod
 > > Cc: TAG
 > > Subject: Re: Namespace dispatching
 > >
 > >
 > >  Paul, the TAG,
 > >  I'd like to voice my support for this view. I don't see what do
 > > processors gain from the XSLT shortcut. I can see what people
 > > gain, but then is anybody left who thinks XML is/should be
 > > readily human readable? 8-)
 > >  And the xslt:literal wrapper proposed by Paul disturbs
 > > readability very little, while adding dispatchability, so to
 > > speak. 8-)
 > 
 > Maybe I'm missing something but how would this solve similar problems with
 > other vocabularies?
 > 
 > For instance, I may have an XHTML document, which somewhere inside contains
 > XInclude instructions. I'd have to run this through an XInclude processor
 > before it can be passed to the browser.
 > 
 > So, while the XSLT problem can be worked around, I don't think this can be a
 > general solution....
 > 
 > Julian
 >

Received on Wednesday, 20 February 2002 18:53:40 UTC