2016-02-02 23:34 GMT+01:00 kovas boguta <kovas.bog...@gmail.com>: > > In general yes, but there are endless specific ways to do this. Do you > represent a kv-pair as a single element? Do you have <key> and <value> as > elements? Or do you use the name of the key as the name of the element? And > then multiply that times the opportunities to use attributes rather than > elements. I've seen all these variations and more. >
> In EDN (and JSON) there is a *specific* literal that represents a Map, > with *defined interfaces and runtime semantics* corresponding to the notion > of a Map. That there are additional ways to encode the information contents > of a Map (but losing its runtime semantics) is obviously true and > irrelevant. > In a better world, those alternatives would be equally irrelevant in XML as well. It's unfortunate that the preferred representation for kv-types in xml (tag attributes) is so limited that formats will use tag content, even when ordering is irrelevant. Huh? Is there an optimizing XML reader that automagically detects all the > possible variation of a Map encoding and generates an optimized backing > datastructure? > Let's not conflate the "ground" xml tags and the runtime structures which they are supposed to map to (this distinction also exists for edn, but is not pronounced there, since its has everything commonly found in simple "config" data, did you know that fressian encodes maps as #map [k v k v ...]) When dealing with ground tags generically (like data.xml does), i.e. the mapped-to structures add no information over the ground tags, I'd say it would be still pretty easy to create a reader, which uses optimized structures for content-only, or attribute-only tags and the like. Even common things like space-separated (class-) lists in attribute tags, ... Dynamic runtimes can also optimize for object shapes "automagically". For reference, google optimization tips for v8 Of course, none of this will decide for you that ordering of your child tags is irrelevant and that it can be used to facilitate O(1) hash-lookup. Thus it _is_ unfortunate that there exists no accepted standard for encoding arbitrary associative structures in XML, because it pushes you towards app-specific representations. When talking about app-specific structures, which deserialize from xml: Here you're down to coding against a specific schema and your runtime's efficiency will be dominated by the pull parser and your builder pattern. Well, show me an evaluator that directly operates on ascii-serialized EDN >> (or even binary-serialized fressian) and I'll agree on this. >> > > I'm talking about the programmatic API. > In this case, the problem still doesn't go away EDN. Sure, it has more builtins, but e.g. when working with graphs, I'll still need to know how to decode my #graph/edgelist [[:a :b 2] [:b :c 1.7] [:c :a #complex [1.7 0.3]], possibly transforming it into a more domain-specific representation in the process. OTOH when passing around a graph as a blackbox, I'll not need to know its internal structure in XML or EDN either. -- 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.
