On Thu, Nov 02, 2006 at 05:10:06PM +0000, Nic James Ferrier wrote:
> Daniel Veillard <[EMAIL PROTECTED]> writes:
>
> > If schematron really depends on XSLT support (bad IMHO) then it need to be
> > removed from libxml2, and either made part of libxslt or another library.
> > Definitely not a small change, my punition again for attempting to implement
> > a spec which wasn't completely formalized (or for which the formal final
> > spec was not available to mere mortals)...
> > Deadlock, as part of libxml2 this is not solvable, best way forward to
> > really
> > implement that would be to start deprecating libxml2 Schematron
> > implementation
> > and move it to another module. Probably not the best way to promote the
> > spec.
> > And if there is really a hard XSLT dependancy then sticking to a stylesheet
> > based implementation (which should work with xsltproc) sounds the
> > simplest.
>
> If it's only a few functions could we just reimplement them in
> libxml2's xpath?
Some of them are fairly tied to the XSLT infrastructure
http://www.w3.org/TR/xslt#add-func
and clearly key() for example would not be reusable in that context.
I would not be able to add them to basic libxml2 XPath, it really should
only see the normal XPath-1.0 function (or if xslt with a namespace
which would just not work with direct generate-id() use). Those would
have to be copied in the schematron module and registered when creating
the validation context' XPath context.
So which functions ?
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
[EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
_______________________________________________
xml mailing list, project page http://xmlsoft.org/
[email protected]
http://mail.gnome.org/mailman/listinfo/xml