OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-apps message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: DOCBOOK-APPS: Re: conditionalization of XML


On Fri, Oct 11, 2002 at 06:36:21AM -0400, Eric S. Raymond wrote:
> Daniel Veillard <veillard@redhat.com>:
> >   I'm not convinced that one need acces to the DocType to conditionalize
> > *processing* . And I'm definitely convinced that it's useless to try to
> > add support for an unstructured processing within an XML toolkit.
> 
> The problem with not being able to see the doctype is that that means
> you cannot pass it through transparently.  XSLT cannot reproduce on its
> output what it can't see on its input.  That's why I gave up on XSLT -- 
> because *any* stylesheet-based approach to conditionalization will have
> the same problem.  

  You want to do 
    XML ---- process X ----> xmlsubset ---- transform ----> web or print

process X standalone can't be done easilly with XSLT, yes.

    XML ---- process X + transform ----> web or print

can be done with XSLT assuming the way you tags things integrate okay
with the markup, which is *not* the case with PIs

> xmlif my be inelegant from a pure XML point of view, but it is
> certainly not useless.  I'm using it quite effectively every time I 
> render my document -- in fact it gives me important capabilities I
> would not otherwise have.  Perhaps you should reconsider your
> definition of "useless"?

  "useless to try to add support for an unstructured processing
   within an XML toolkit"

 yes I stand on this, not the proper place. You must understand that
at that level I have an in-memory tree and that your <?if?> <?else?> 
are just PIs scattered around the tree and if they are not properly
instanciated w.r.t the structure the whole processing fall over.
And a solution based on markup tags/attributes and not PIs is likely
to be quite simpler to describe fully.

> >   I don't want to add an add-hoc unspecified unstructured processing
> > to my toolkit and maintain it. Show me a more coherent request and
> > I will re-evaluate it. Mind you I have work to get done too !
> 
> I don't know what you would consider a coherent request.  Do you want
> a more formal specification of the behavior of the PIs?

  Yes with respect to structure, error handling etc ... And get traction,
checking that others are interested in it and have reviewed it.
This thread between you and me could go on for ages, it's not the point
I don't want to implement something which might be architecturally broken
or too limited to be widely useful. You may have 100 MBytes of markup
tagged this way, but this won't be the reason why this should be added
at the toolkit level. You claim to have the magic solution, I want to hear
more voices before commiting on it, especially since I'm not personally
convinced it's the right technical approach.

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard@redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC