http://dev.clojure.org/jira/browse/CLJ-2030
--
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 un
So, your comment about using uri-encoding inspired me to just use that as
an encoding to fit in a kw-ns. It seems to work out:
https://github.com/bendlas/data.xml/commit/22cbe21181175d302c884b4ec9162bd5ebf336d7
There is a couple of open issues, that I commented on the commit.
I'll open a dev-thr
What about skipping the alphabet translation and just doing uri encoding?
{http://www.w3.org/1999/xhtml}pre => :http%3A%2F%2Fwww.w3.org
%2F1999%2Fxhtml/pre
doesn't seem so bad and this way we would get uniformity without weird
corner cases.
--
You received this message because you are subscribed
No escape needed; or, rather, no need to invent an escape. A mapping from
IRI to URI is already specified in RFC 3987, "Internationalized Resource
Identifiers (IRIs)". Just translate IRI to URI, and thence to keyword.
--
You received this message because you are subscribed to the Google
Gro
2016-09-17 15:10 GMT+02:00 Matching Socks :
> To make a URI into a Clojure keyword namespace, we may simply replace
> the 11 URI characters that are forbidden or problematic in keywords
> with Unicode-alphabetic characters outside Latin-1.
>
Yep, I've been thinking along those lines as well. We'd
To make a URI into a Clojure keyword namespace, we may simply replace
the 11 URI characters that are forbidden or problematic in keywords
with Unicode-alphabetic characters outside Latin-1.
The substitutes should be present in common desktop fonts, and should
not be mistaken for Latin-1 characters
2016-08-25 1:53 GMT+02:00 Matching Socks :
> Namespaced XML is inherently value-comparable and unambiguous. It would
> be shame to give up on that, and disperse the burden throughout every layer
> of library and consumer.
>
That's a very good point. Disregarding concerns for edn syntax for a
mom
Namespaced XML is inherently value-comparable and unambiguous. It would be
shame to give up on that, and disperse the burden throughout every layer of
library and consumer.
Pretty-printing need not be a concern of the XML parsing library. Everyone
seems to be interested nowadays in easing the
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 ex
Apps are cobbled together from sub-systems and libraries. Some of those
may use clojure.data.xml, either to share their products with their client
or for their internal purposes. As soon as two libraries on Clojars differ
in their namespace-URI to keyword-namespace mapping, has the ship sunk?
2016-08-20 21:43 GMT+02:00 Matching Socks :
>
> Could the same effect be obtained without the global state of namespace
> mappings? Do all uses of clojure.data.xml in an app, even fully
> encapsulated uses, have to agree about the keyword for any given well-known
> XML namespace URI?
>
Currently
The future is XML-with-namespaces: POM files and whatnot. Such cases are
tricky because more than one notation is possible. You need a
namespace-enabled parser to figure out what the XML text really means.
Luckily, a contributed project, clojure.data.xml, can read
XML-with-namespaces, and in
12 matches
Mail list logo
