[
Lists Home |
Date Index |
Thread Index
]
Agreed. Dave Durand made me see this clearly
during the XML WG days with the phrase "magic
object pixie dust", a phrase now repeated so
often that he may be regretting it, but still
pertinent.
It's one thing to implement a bound approach;
it is another to insist on it as the only
way to apply XML. XML enables many approaches,
but I assert again, portable data and interoperable
systems aren't the same requirements, and blind
interoperation anywhere anytime with any resource
is a daunting problem if other considerations such
as performance, validity, safety, security, etc.
enter the picture.
I assert that a minimal XML framework strawman
is a useful document. It might be one way
to cast light in the dark obscure corners of
the use cases put forward as a basis for deriving
requirements. We can't get that from the W3C
and certainly not from the TAG; yet taking the
draft architecture document due soon from the
TAG, then applying that to a mimimal XML framework
design would be a worthy exercise here on
XML-Dev.
What is the least one can get away with and work
with REST principles under the TAG architecture
draft? How clever can one really be before the
optimizations make the implementation fragile?
len
-----Original Message-----
From: Manos Batsis [mailto:m.batsis@bsnet.gr]
Absolutely. But typing in it's OO sense is not the complete answer to
XML problems. Inconsistent, incomplete APIs and luck of control is part
of the problem IMHO. Hiding XML behind classes may be a strong
convenience but current problems are much simpler and directly related
to control over the Infoset.
What worries me even more is that the "progress" in the form of new
drafts does not deal with such issues as much as I would like them too;
instead I see more and more energy behind the OO features related to XML
Schema, like someone took over XML development or something and pushes
everything under the new rag.
|
