>What am I missing? Why is this URL approach a superior solution to setter
methods?
What you're missing is that this isn't just a Xerces API. It's shared with
other parsers, which may support a different subset of features. Using a
string-based approach to naming the features avoids having to do reflection
tests or other magic to handle requests which a specific parser
implementation can't handle... or ones which they do but Xerces don't.
And once you go with strings in order to support that extendable feature
set, URIs become a reasonable solution for the same reasons that they were
used in XML namespaces: everyone already understands how to manage URIs so
two companies/standards organizations/whatever don't wind up with
conflicting definitions for the same string.
Yeah, there's a verbosity problem. But it's generally fairly minor.
______________________________________
Joe Kesselman, IBM Next-Generation Web Technologies: XML, XSL and more.
"The world changed profoundly and unpredictably the day Tim Berners Lee
got bitten by a radioactive spider." -- Rafe Culpin, in r.m.filk
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
