[
Lists Home |
Date Index |
Thread Index
]
> Which is to say, there's nothing wrong with inventing new XML
> APIs, go
> to it, just don't fool yourself that there's One True API out there
> waiting to be found. Presumably we can end up with a number of APIs
> that is greater than one and smaller than the total number of
> applications. -Tim
Right. The question is now back again as to whether there are two main camps
in XML: those who need types and those who don't. Even that's an
oversimplification, but it may fit the 80/20 rule. :0)
Those who need types are those who are going to store character data in
language primitives. It may prove useful to them to know that a data item is
an integer. It may not be an integer that is lexically understood by the
application, in which case a locale formula has to be developed that
translates the incoming lexical representation to a native one. But you
know it's an integer, so you know there is some way to do it.
Specifying value spaces (ranges, for continuous value spaces) would be an
interesting trick: you can't do it without resorting to a lexical
representation of some kind. Maybe that's done narratively, through a spec
doc (or mathematical proofs), or maybe it's possible (I don't say likely),
that there's a cannonical representation for a type that everyone can agree
to, if not use locally.
And then maybe we should just shove type information in the documents
themselves. I think you could subvert the namespace prefix mechanism to do
just that. Truly evil. But we needn't call it XML. Call it Typed
Metalanguage (TML), and make it backwards compatible with XML.
MUHAHAHA...
|
