Le 04/05/17 à 16:20, Rick Jelliffe a écrit :
> That is why I think an extended DOM/XDM is necessary, the ideal
> approach for XSLT for this kind of thing is for XPath to add a
> special axis for accessing unnamed 'elements' (if it is JSON as
> content in XML,) or unnamed 'attibutes' (for XMON syntax.)
I have been thinking about an extended DOM/XDM for years
(https://www.balisage.net/Proceedings/vol10/html/Couthures01/BalisageVol10-Couthures01.html
and
http://www.agencexml.com/amsterdam2015/Processing_non-XML_sources_as_XML.pdf)
and my own Javascript implementation, for browsers and nodeJS, is now at
alpha level with XPath/XQuery support. Because I chose to have my own
DOM3 implementation, it was very easy, "for fun", to run xqib.org
examples with it.
Working at DOM level, of course, allows to add node types, axes,... and
specific parsers for non-XML data. Having its own XPath engine allows to
add operators and so on (I have chosen full asynchronous evaluation
because of functions like fn:doc(), http:send-request(),...).
I am happy with it for my own purposes and it's free opensource but I
know that, nowadays, nobody is effectively interested in it but me...
Best regards,
Alain Couthures
