[
Lists Home |
Date Index |
Thread Index
]
Bill de hÓra wrote:
> Alaric B Snell wrote:
>
>> One way of making it type system agnostic is to define the types in
>> terms of the type system of the programming language you're using it
>> from.
>
>
> Al,
>
> Like the DOM? No thanks ;)
Maybe or maybe not like the DOM - exactly what bit of it are you
disliking in this context? :-)
My reasoning was that the only type system that a program reading XML is
definitely constrained by is its own. Any given schema language's type
system is only optionally relevant to the programmer, but if you're
coding in Java, then your integers are going to be "int" or "long" or
that arbitrary-precision number class I've seen in the javadoc but never
played with, pretty much!
And since this "give me the data as abstract values rather than strings
I need to manually invoke the appropriate parser on each time" SAX
option is just optional, and in the presence of imperfect type
information (eg: the input is not actually valid with respect to the
schema! It doesn't need to be a validating parser to use the schema...)
then it would presumably just call the "characters" callback whenever it
came across something it was unsure about. Note that when it encounters
a string it knows to be of a schema-type that maps to a string, it would
call the value callback with a string value - that's a distinct case.
So somebody who was writing a strict reader that should barf on all
invalid things could write a characters callback that just throws an
exception. Somebody who was using an experimental new type that the SAX
parser didn't natively understand would just invoke their own parser
from the characters callback, like we do for everything nowadays -
meaning you're not constrained by the type information. The API can be
designed to handle exceptions to the typing constraints in a non-fragile
manner.
> Bill de hÓra
ABS
|
