[
Lists Home |
Date Index |
Thread Index
]
Joe English wrote:
>
> Simon St.Laurent wrote:
> >
> > At 02:44 PM 5/29/2003 -0700, Joe English wrote:
> > >[...] the nice simple data model of elements, attributes,
> > >and text turns into a vastly more complicated data model, where
> > >names are <namespace-name,local-name> pairs -- or even worse,
> > ><namespace-name,namespace-prefix,local-name> triplets -- instead
> > >of atomic strings, and you have to keep track of the namespace
> > >environment to serialize or deserialize anything.
> >
> > There are people who argue that you could just borrow someone else's pain
> > and use an off-the-shelf parser with a standard API,
>
> But _are_ there any toolkits that handle namespaces sanely?
> I haven't found any yet. (SXML comes pretty close though).
>
humor me.
take a second and look as the class definitions for the document model which
cl-xml targets.
the document model is expressed entirely in terms of an abstract name type,
which can be implemented either with symbols or with clos instances. if one
decides to use symbols, no operations particular to namespaces appear anywhere
in application code. if one is concerned about more refined control over the
scope and extent of namespaces there is an alternative which behaves roughly
the same, but offers better protection against things like resource-based
attacks. in that case one needs to be aware of whether the namespaces are
defined statically or exist relative to documents / document models.
over the two years since i first posted cl-xml i get intermittent mail when
some ansi compatibility in my code turns up against some vendor's new release.
i get intermittent mail about some bug or other.
the only question i can recall getting which was related to namespaces
concerned an early version which interjected the declarations for xml and
xmlns in the root element of serialized documents. i fixed that when the
related entry appeared in the namespaces errata.
if one can program lisp (ie, if you know what (eq 'a 'b) means) one can write
lisp programs which work on xml documents without learning anything new. names
are modeled as atomic interned objects - either symbols or clos instances. the
parser/serializer handles them completely transparently as first class objects.
as demonstrated by this, there is no need for special application namespace handlers.
none.
> > but that doesn't
> > always work for my tasks - too much gets lost along the way. Fortunately
> > I've now written stacks for handling namespace declarations (and scoped
> > attribute values), so the worst of the pain is over, but the smaller
> > symptoms linger.
>
> The initial namespace processing seems like the easy part
> to me. It's working with the output of that process that
> I find painful, for exactly the reasons listed below:
>
> > It seems like namespaces aimed at diambiguation with the "let's create big
> > long names" approach, and then had to abbreviate the big long names to keep
> > the language usable. Since then, we've had datamodels that are big (pairs
> > and triples), complex (scoped), and infectious (QNames in attribute and
> > element values).
>
> Another model is to just use the big long names; that's
> what JDOM and SXML do. This isn't any more appealing
> to me than pairs or triples, though, and the scoping
> problems remain.
>
> --Joe English
>
> jenglish@flightlab.com
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
|
