2014-05-21 21:06 GMT+02:00 Paul Gearon <gea...@gmail.com>:
>
> Are QNames strictly necessary? Keywords seem to do the trick, and they
> work in nicely with what already exists.
>
> I know that there are some QName forms that are not readable as a keyword,
> but the XML parsing code will always call (keyword ...) and that holds any
> kind of QName,
>
I've argued this at some length on the dev thread. IMO QNames are not
nessecary, but we want another datatype than keywords.
I think the main argument for using keywords would be xml literals in code
and there readability (i.e. not having to use (keyword ..)) counts. A
reader tag is far better suited for this.
In the course of that argument, I also came up with a way to represent
resolved names as keywords in literals. Please check out the design page
for this.
Are the reverse mappings (uri->prefix) definitely necessary? My first look
> at this made me think that they were (particularly so I could call
> XMLStreamWriter.getPrefix), but it seemed that the XmlWriter keeps enough
> state that it isn't necessary. My final code didn't need them at all.
>
The XmlWriter does keep enough state, but I also want to support tree
transformers that have the full information without needing to pipe through
Xml{Reader,Parser}.
uri->prefix could be reconstructed from prefix->uri in linear time, so
again, the reason for the reverse mapping is performance.
I was mostly considering round-tripping the data, and the parser is good at
> not repeating namespaces for child elements, so the emitter didn't need to
> either. As a result I didn't need to filter out prefix->uri bindings from
> parent elements when emitting namespaces, though that should be easy.
>
What I meant are redundant prefixes, e.g. binding xmlns:D="DAV:" at the
root element, xmlns:E="DAV:" in a child element.
> If uri->prefix is needed, then a simple map would need that, yes. However,
> if I needed the reverse mapping then I'd use a pair of stacks of maps - one
> for each direction.
>
> (BTW, a "stack of maps" sounds complex, but the top of the stack is just
> the new bindings merged onto the previous top of the stack).
>
In this case, XmlNamespaceImpl is just that, modulo the stack. It is meant
to be updated at every child element that binds xmlns prefixes, so the
stack is implicit. I don't keep the parent XmlNamespaceImpl, because an xml
element doesn't keep a parent pointer either.
ad. Thomas' quesion
> Slightly Off topic, but how can I add new an element to an existing XML
file with data.xml.
Since you mentioned zippers, I assume you are familiar with them. I
wholeheartedly recommend them for manipulating xml.
Enlive is also built on zippers and I think it shouldn't take too much
effort to make it work with the proposed namespace support.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
