Eric van der Vlist wrote:
This is controversial, but yes, I do think that it's a good practise :-)...
I can see how this can be controversial ;-)
I would say for foreign attributes and for foreign elements where they are not too troublesome, ie in complex contents. The problem with allowing foreign elements in simple contents is that they transform these simple contents in mixed content models that are much more tough to process.
We had recently a similar question related to the particular case of XInclude, which doesn't work out of the box with the PFC and XPL because the schema is too restrictive. Not because of the actual xi:include elements, but because the result of the inclusion produces xml:base attributes. Here, we clearly want to allow those attributes. But the plan was to specifically allow for xml:base.
In that two cases (foreign attributes and foreign elements in simple contents), many applications using DOM won't even notice these additions and other applications can easily be programmed to ignore foreign namespaces.
Still, while not much more difficult to code, it makes testing more difficult: you must test your application by providing documents that can pretty much contain random elements and attributes all over the place. A little drawback, which is not problematic if there are benefits to balance this.
In the case of XHTML, that's a controlled openness, with practises described in the modularization of XHTML, but still, I think that this openness is the foundation that has made XForms possible.
It definitely makes sense for XHTML and for that kind of document formats in general, because the notion of embedding / compounding is necessary (or at least very convenient and accepted practice) for such applications. E.g. embedding SVG or MathML in XHTML. I am 200% sold on this one.
For custom annotations though, I am not quite sure. Won't your XPL and PFC files look overloaded and confusing if people start annotating left and right with their own elements? I am comparing this approach to the XML Schema approach, where user content is restricted to very specific places.
In another area, probably closer to XPL than XHTML, schema language annotations enable all kind of interesting applications that I have described in a chapter of my RNG book : http://books.xmlschemata.org/relaxng/RngBookAnnotations.html .
I remember now that Relax NG allows this.
Not that this is actually a great solution, but I should mention that you could use XSLT to clean-up the PFC document. The PFC is actually a processor like any other, with a "controller" input taking the PFC configuration. Instead of using the Page Flow processor as main processor in the application, you could use the Pipeline processor instead. That pipeline would read the PFC configuration, filter it, and send it to the PFC processor. Assuming both the PFC file and the stylesheet are static, caching will make sure that there is no performance hit.
With this solution, you could have your own annotated files today. The PFC receives them clean of annotations, but of course your own code uses them with the annotations.
-Erik
------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ orbeon-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/orbeon-user
