This design document covers a superset of the clojure.xml schema.
All metadata are optional, parsers SHOULD provide them and serializers MAY leverage it: metadata is not required to be kept in sync with their data so it's up to the serializers heuristics to use or ignore them.
Namespaces
A namespace aware XML parser produces a datastructure following these representations, this representation is designed as a superset of the clojure.xml representation:
| XML | Clojure | Notes |
|---|---|---|
| Element | ^{::xml/ns {"" "http://..." | A map with keys: :tag (local name keywordized), :attrs (attribute map), :content (nil, sequence, sequential collection of nodes), :uri (namespace URI as string). Metadata: under the ::xml/ns key, a map of prefixes (strings) to URIs (strings), under the ::xml/prefix a string of the original prefix. (where xml is an alias for data.xml) |
| Attribute | ^{::xml/ns {"" "http://..." | A map entry whose key is either a keyword (no prefix) or a [:kw "uri"] pair; the value is a string. In the case of [:kw "uri"] keys, ::xml/prefix SHOULD be present the uri MUST NOT be nil or the empty string |
| Text nodes | "text" | |
| Comment | {:comment "text"} | |
| ... | TBD |
Default serialization strategy suggestion
The default serialization strategy is conservative.
When serializing an element: add missing namespaces declarations.
For each name (elements or attributes name):
- If the ::xml/prefix matches the :uri then use it,
- if the uri is mapped to another alias, use it, (Should we rather map the url to the new alias?)
- if the uri is not mapped then map it under the specified alias (if present) or a gensymed alias.
For elements:
emit xmlns and xmlns:* attributes for new mappings (generated by attributes serialization and by new entries under the ::xml/ns key – new when compared to the state maintained by the serializer).
Custom serialization strategies
To please broken consumers, XML serialization has to be tweaked. It may be interesting to have emit or *xml-emitter* or somethieng to be a dynamic var.
Less than half-baked idea:
Defining a full serializer is tiresome so it may be interesting to provide a factory.
All serialization quirks can't be solved by emitters produced by such a factory but if it covers a good chunk it may be worthy.
There must be a better abstraction.
1 Comment
Hide/Show CommentsApr 21, 2013
Andy Fingerhut
In case someone would like to see some of the discussion that led to this proposal: https://mail.google.com/mail/?shva=1#search/label%3Aclojure-dev+xml+namespace/133d1336770e59c5