I've been thinking this over. I'm starting feel that you are right in that the arbitrary, global mapping could cause more problems, than it would solve. Even if we could get by with a maintained registry, it would still be a burden to maintain and to use. Also, there is the open question of code expecting qnames, when suddenly, somebody declares a new xmlns mapping.
There is the possibility to canonicalize by cramming the xmlns uri into a readable kw-ns and that would still neatly reuse clojure's ns-alias facility. What I don't like about the approach is, that it would make even pretty-printed xml parse-trees quite unreadable. While :xmlns.dav/multistatus vs :xmlns.REFWOgo=/multistatus might not look as horrifying, consider :xmlns.aHR0cDovL3d3dy53My5vcmcvMTk5OS94aHRtbAo=/p for an xhtml paragraph. Maybe it's time to give up on universal value equality of parsed xml and instead make the keyword - mapping a la carte, with a parser / emitter flag. Technically, universal value equality is already challenged by the qname / keyword dichotomy and given that we want to retain using ::alias/keywords there is a decision to be made on whether to make qname the canonical representation and embrace the multitude of keyword mappings or whether to eliminate qnames and take the readability hit for canonicalizing the keyword representation. Do you see any alternative? -- 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.
