Hi Paul,
2014-06-06 17:28 GMT+02:00 Paul Gearon <gea...@gmail.com>:
>
> I've split up the namespace pretty much the same way that you did (since I
> totally agreed with that). To that end I ought to put your name down as the
> author, though I typically end up changing things in each file, so it's got
> my mark on it too. Is the standard for the namespace :author tag to use a
> comma separated string?
>
I'm not aware of any convention here. To me it's also fine if you just put
your name.
> Parsing goes to the representation tier, which is compatible with the
> existing clojure.data.xml output. As mentioned before, the changes are a
> new namespaces field, and metadata to hold the contextual namespaces (so
> it's invisible to printing, equality, etc). For the test data I've used,
> emitting the representation tier generates the original XML (with new
> formatting).
>
OK, I don't think that adding a separate namespaces field is compatible
with existing output, but it's a change that makes sense in a certain light.
I would still oppose that change, in case it should be proposed.
This data format contains each of the elements of your infoset
> representation. So your model tier example in the design doc of:
> <D:propfind xmlns:D="DAV:" />
>
> Maps to your representation of infosec:
>
> {:tag ::dav/propfind :attrs {} :in-scope {"D" "DAV:" "xml" "<xml-uri>"}
> :namespace-attrs {::xmlns/D "DAV:"}}
>
> Whereas my code represents the same data with:
>
> (with-meta
> {:tag :D/propfind :attrs {} :namespaces {"D" "DAV:"} :content ()}
> {:xml "http://www.w3.org/XML/1998/namespace"})
>
> So it's the same info, but represented differently.
>
My proposed model tier would be leaning on xpath, because it fits with
clojure.core/=. So that would be:
(with-meta
{:tag #xml/name "{DAV:}propfind" :attrs {} :content ()}
{:clojure.data.xml/namespaces (xml/to-ns {"D" "DAV:"})}) ;; xml and xmlns
prefixes are added by to-ns
I don't intend to implement the infoset or the dom representation at all,
sorry that the design page is unclear on that.
The ::dav/propfind convention is convenience for notation, it doesn't
interact well with equality, so there would be a special version of =
and/or a converter.
I'm sure that you are aware that your proposed representation doesn't work
with clojure.core/=, so I'm not going to dissect the issues there.
Let me add that people might want to store arbitrary metadata on parsed
xml, so using a namespaced key there is prudent.
I've also implemented a resolve-xml function (I'd have liked "resolve", but
> I hate reusing names that appear in clojure.core). When applied to data in
> the representation tier it generates a version of the model tier. This uses
> QNames for tags and attributes. They are still QNames even when they do not
> have a namespace, since QNames support this. This transformation was easy,
> as it just applied the namespace info to the keywords in the representation
> tier. I was expecting to create a new Element type to represent the model
> tier, but in the end I didn't see the need, since the existing types do
> everything needed for the model tier as well. The main reason I can think
> of to create a new element type for the model tier would be for a tree
> walker to be able to use protocol dispatch on the element and not the
> contents of the element.
>
Cool, maybe I can steal your converter? I have only implemented parsing
directly to model tier, for now.
- a function to go from the model tier to the representation tier. I hope
> to do this soon.
>
So, basically a prefix-assigner for model tier
> - graceful handling of un-mapped prefixes
>
I'm still thinking hard about erroring out in this case, as StAX does, IIRC
> - handling a default prefix (the pseudo-raw section of the design
> document)
>
I think that this can be modeled as the empty prefix.
> - The QName reader
>
I've already written that, I'm just not sure how to deploy it in a contrib
project.
Thanks for following up on this, I'll make sure and ping you, before I get
back to my version.
cheers
--
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.
