[
Lists Home |
Date Index |
Thread Index
]
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).
> 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
|
