[
Lists Home |
Date Index |
Thread Index
]
Elliotte Harold wrote:
> Joe English wrote:
> > When I complain about namespaces, it's just the opposite:
> > I *don't* want to have to use URI/localname pairs everywhere.
> > I'd rather treat element type names and attribute names
> > as simple, atomic strings. This is possible with a sane API,
> > but most XML APIs aren't sane.
> >
>
> Interesting. What would such a sane API look like? Are you envisioning
> something more along the lines of XPath/XQuery/XSLT where the program
> has its own list of namespace bindings that it uses to transparently
> resolve qualified names?
Pretty much, yeah. The basic idea is, the application declares
each of the namespaces it's interested in along with their
preferred prefixes. Then when a document is parsed, element
and attribute names are rewritten to use the application's
namespace prefix bindings. This gives application authors
the same kind of convenient shorthand that the Namespaces REC
gives document authors.
There are a couple issues like what to do with the original
namespace declarations (keep them? transform them? throw
them out?) and namespaces that the application didn't declare,
but those are minor and easily dealt with.
> Or are you thinking more of something like
> DOM1/SAX1 that pretty much ignores namespace bindings?
What I tend to use nowadays when I have to handle
namespaced documents is a SAX1-equivalent for parsing,
followed by a "namespace sanitizer" that does the above
transformation, followed by a DOM1-equivalent [*] for
the bulk of the work. That keeps the places where I
have to deal with namespace URIs at the edges of the
process; in the middle I almost never have to worry
about them.
--Joe English
jenglish@flightlab.com
[*] Equivalent in the sense that element and attribute names
are atomic strings instead of URI/localname pairs or
URI/localname/prefix triples, not equivalent in the
sense of having all the features (mis- and otherwise)
of DOM Level 1.
|
