Hi Herwig, Thanks for the response.
I'll remove some of the less relevant bits as I reply inline... On Wed, May 21, 2014 at 2:26 PM, Herwig Hochleitner <hhochleit...@gmail.com>wrote: > 2014-05-21 19:31 GMT+02:00 Paul Gearon <gea...@gmail.com>: > >> I like the way that you have split the implementation of functionality >> into different namespaces. The current release is a little monolithic. >> > > The patch I attached to DXML-4 [1] are just minimal changes to make > roundtripping work. No refactoring. > > I've started to implement a much more advanced approach to namespaced xml > in my repo [2], the design of which came from feedback on clojure-dev > thread [3] and is documented in a new design page [4]. > I wasn't really paying attention to the patch, since I saw your link to your fork. Someone mentioned the thread to me, but I hadn't found it yet. Thanks for the link. I'll read up on it, along with the design page. I'll continue to comment while I'm here, though I may get some of my answers as I read more. This approach will add another data tier (and make it the default), where > tags and attribute names will be represented as QNames and xmlns attributes > won't be present in :attrs > 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, > One thing that bothers me is what's going on in clojure.data.xml.impl. I >> haven't tried to go through all of it yet, but I didn't think that the code >> needed to be that complex. >> > > Good thing that you didn't bother consuming it all, impl currently has a > lot of code, that will get deleted again. Basically all the stuff for > automagically mixing raw and resolved data. > The relevant parts for now are mostly XmlNamespace and the reader tag > implementations. > > The way I handled prefix-uri mappings was to use a stack of maps, which I >> thought was adequate. Your implementation of XmlNamespaceImpl has me >> thinking that I've been missing something important. Could you explain why >> XmlNamespaceImpl is structured the way it is? >> > > Apart from basic bidirectional mapping functionality, XmlNamespaceImpl is > built in such a way that: > - Adding mappings is semantically equivalent to a child element declaring > xmlns attributes > - A new prefix for an already established mapping won't displace the > current reverse mapping (uri->prefix), but get recorded as an alternative > - Remapping a prefix to a new uri or deleting it, will establish an > alternative prefix for that uri, in FIFO manner > 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. I thought I covered the various cases, but I could well believe that I missed one, since there are so many ways to represent the data. Do you have some good examples? The aim is to strip out redundant xmlns attributes in the emitter, while > retaining xml semantics. There is indeed something missing: Two > XmlNamespaces must be diffable, to discover which xmlns attributes actually > have to be emitted. > 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. > I'm sure it could be built a lot simpler. It's currently basically a > product of making its tests work [5]. It could probably be made to work > with stacks of maps, but then each lookup would involve a linear search, no? > 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). > What do you think of the proposed design? > I will take the time to go through them, thanks. Even if it ends up different to how I'd do it, it'll be the core library, and I need to work with it no matter what. Thanks for being on top of this. I'm looking to reimplement a parser in Clojure when 99% of the world is using a single Java library for this job. That's no good for diversity (as OpenSSL showed recently) and also because I can hardly say I'm offering an alternative system when core elements are built on the same library that everyone else uses. It's a W3C standard, so it makes ridiculously heavy use of namespaces. :) Regards, Paul -- 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.
