Hi Erik,
On Fri, 2004-09-24 at 00:32, Erik Bruchez wrote:
> > > - Can I use document() in an XLST transformation that points to an XPL
> > > file that gets executed?
> >
> > That"s something I have thought about. I don"t think that its
> > possible right now (except of course if you wrote your files on
> > disk but I wouldn"t advise that) but I"d like to submit an idea to
> > the development team here...
>
> This is not possible at the moment. We would have to implement a new
> protocol to supports this. Another suggestion was to implement XSLT
> extension functions. Yet another one was to provide a processor
> supporting pipeline and/or PFC inclusion inclusion "tags" (ideally a
> generic "tag library" system).
Hmmm... I am really confused here: why do you say it's not possible when
you explain later on that 99% of it is already implemented?
Do you mean that developing a new protocol isn't possible at the moment?
> > Since XPL requires that you declare the inputs, why not allow to
> > declare other inputs than just "config" and "data" for the XSLT
> > processor and provide a protocol to access these inputs by name
> > from the document function?
> >
> > That could give something such as:
> >
> > <p:processor name="oxf:xslt">
> > <p:input name="config" href="oxf:/lucene/affiche.xsl"/>
> > <p:input name="data" href="oxf:/lucene/cherche.xhtml"/>
> > <p:input name="request" href="#request"/>
> > <p:output name="data" id="xhtml"/>
> > </p:processor>
> >
> > and, in the XSLT transformation something such as:
> >
> > <xsl:apply-templates select="document("input:request")"/>
> >
> > where "input:foo" would mean the input named "foo".
>
> This is an excellent suggestion. So much so that it has been
> implemented since a long time ;-) You can access the additional inputs
> with document('oxf:blah'), where "blah" is the name of the input. I am
> now wondering why this is not clearly documented.
That's good news and will help me a lot for the prototype I am
developing for XMLfr.
> > I think that this would be very flexible and easier to use than
> > aggregates where you get to know the position of each input that is
> > aggregated while here, you"d access the inputs by name.
>
> This is exactly the reason why we decided to implement it this
> way. The XUpdate processor also supports the same syntax, and this is
> in fact often used with Page Flow, with document('oxf:action') and
> document('oxf:instance'). I think your suggestion of using the
> protocol "input:" is not bad. We went with "oxf:" at the time, but it
> may become confusing as "oxf:instance" means a reference to an input,
> while "oxf:/instance" means a reference to a resource.
I think that it would be nice if that was easier to implement new
protocols by providing a layer that could be overridden a little bit
like SAX entity resolver.
I had hoped that resource managers could be this class and it doesn't
seem to be the case since they seem to be only acting on the "file:"
(and probably "oxf:") protocols. As far as I understand, they belong to
a layer that is after the protocol has already been interpreted.
If that's the case, a (naive) solution might be to support XCatalogs.
Then you would be able to match a new protocol to files locations and
the resource manager could direct these files locations to anything you
like.
Another one (probably saner) would be to extend the scope of resource
managers so that they can intercept the read/write requests for all the
protocols. In that case, a resource manager could implement XCatalogs.
Or maybe a maybe a mechanism could be added so that you can just
register resource managers to protocols.
Of course, I am probably wrong since I am still missing important pieces
in my perception of the overall architecture of Presentation Server.
Eric (in brainstorming mode)
--
If you have a XML document, you have its schema.
http://examplotron.org
------------------------------------------------------------------------
Eric van der Vlist http://xmlfr.org http://dyomedea.com
(ISO) RELAX NG ISBN:0-596-00421-4 http://oreilly.com/catalog/relax
(W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema
------------------------------------------------------------------------
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
_______________________________________________
orbeon-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/orbeon-user
