« Return to Thread: Some strengths and weaknesses in Scala's XML capabilities
Re: Some strengths and weaknesses in Scala's XML capabilities
by Arrgh
::
Rate this Message:
May I suggest that we move this discussion to -xml? (cc'd)...
Marcus Downing wrote:
> I believe that using a zipper pattern [1] would allow not all, but most
> xpaths to be handled. It would have some conditions for successful use
> though.
>
> The problem with using xpath for scala.xml is that an xpath rule is allowed
> to refer to parent nodes, while scala.xml's nodes don't contain links to
> their parents. What's needed is a way to access the known parents, without
> compromising scala.xml's immutable nodes.
>
Indeed, I stumbled on http://www.kmonos.net/pub/Slit/index.en.html last
year and thought it might be interesting for an XML navigation idea I
was daydreaming about.
> To implement a more thorough version of xpath, in which queries can
> correctly traverse the whole tree including its root, would require a more
> drastic change - one which I'm *not* seriously suggesting. When an XML
> document is loaded, its nodes are made immutably as at present; however,
> when that document is queried, the nodes returned to the user are in fact
> zippers, wrapping around the nodes and providing information about where in
> the document the node belongs. This distinction is maintained between the
> data themselves, and the zippers that client code executes. These zippers
> would have an implicit conversion to Node, allowing them to behave properly
> if you attempted to copy a node into another tree. To make them sound more
> Scalaish, you could call them something like RichNode. But like I said, I'm
> *not* seriously suggesting that.
>Most XPath libraries require the user to "compile" an expression down to
an AST before it can be used--interrogating the AST would let you know
fairly quickly whether the expression uses problematic axes.
I think the following axes are problematic to some degree with the
current scala.xml node classes:
ancestor, ancestor-or-self, following, following-sibling, parent,
preceding, preceding-sibling
The following should be uncomplicated:
attribute, child, descendant, descendant-or-self, namespace, self
To get around the inability to navigate to the root of a document, we
could just make the user remember and supply the root element in any
XPath API that uses an absolute expression... Or we could play games
with hidden mutation... Uncontended synchronization for objects that
don't escape their creating thread is getting very cheap. ;)
-0xe1a
Marcus Downing wrote:
> I believe that using a zipper pattern [1] would allow not all, but most
> xpaths to be handled. It would have some conditions for successful use
> though.
>
> The problem with using xpath for scala.xml is that an xpath rule is allowed
> to refer to parent nodes, while scala.xml's nodes don't contain links to
> their parents. What's needed is a way to access the known parents, without
> compromising scala.xml's immutable nodes.
>
Indeed, I stumbled on http://www.kmonos.net/pub/Slit/index.en.html last
year and thought it might be interesting for an XML navigation idea I
was daydreaming about.
> To implement a more thorough version of xpath, in which queries can
> correctly traverse the whole tree including its root, would require a more
> drastic change - one which I'm *not* seriously suggesting. When an XML
> document is loaded, its nodes are made immutably as at present; however,
> when that document is queried, the nodes returned to the user are in fact
> zippers, wrapping around the nodes and providing information about where in
> the document the node belongs. This distinction is maintained between the
> data themselves, and the zippers that client code executes. These zippers
> would have an implicit conversion to Node, allowing them to behave properly
> if you attempted to copy a node into another tree. To make them sound more
> Scalaish, you could call them something like RichNode. But like I said, I'm
> *not* seriously suggesting that.
>
an AST before it can be used--interrogating the AST would let you know
fairly quickly whether the expression uses problematic axes.
I think the following axes are problematic to some degree with the
current scala.xml node classes:
ancestor, ancestor-or-self, following, following-sibling, parent,
preceding, preceding-sibling
The following should be uncomplicated:
attribute, child, descendant, descendant-or-self, namespace, self
To get around the inability to navigate to the root of a document, we
could just make the user remember and supply the root element in any
XPath API that uses an absolute expression... Or we could play games
with hidden mutation... Uncontended synchronization for objects that
don't escape their creating thread is getting very cheap. ;)
-0xe1a
« Return to Thread: Some strengths and weaknesses in Scala's XML capabilities
| Free embeddable forum powered by Nabble | Forum Help |
