[
Lists Home |
Date Index |
Thread Index
]
> I would love to reduce the complexity of the solution, but
> I don't think we can deny that the requirement exists.
What about denying that there should be 'a' solution in the first place?
Publishing people work with strings, symbols and sometimes numbers;
where they have a need for complex data-types, they may have to work
with pre-existing dataformats that they don't want to have to convert all
the time. (In particular, for dates.)
Database people have many types based on efficient storage and
access.
Data communications people and i18n people tend to want to mandate
global formats.
They each have separate requirements; meeting any one group's needs
is nice, meeting two group's needs should be enough, but meeting all
three group's needs has proved to be overkill (and, actually, impossible).
XML Schemas has failed to meet the needs for mapping
to standard types for people who have non-XML-Schema lexical
forms (e.g. US dates, Ja/Nein). Why foist an inadequate and convoluted
schema language on otherwise quite straightforward technology such as
XPath? Why increase the difficulty of implementation so much,
if an Xpath system must also be PSVI aware in order to call itself
a full implementation? Why wreck the party for the rest of us?
Cheers
Rick Jelliffe
|
