[
Lists Home |
Date Index |
Thread Index
]
6/11/02 7:46:56 AM, Amelia A Lewis <amyzing@talsever.com> wrote:
>So, is it better to define a type in XML as something that can be
>validated, or as something that maps to type A in language Z, type B in
>language Y, type A again in language X, and type L in language O?
>
>I submit that attempting to define XML types by mapping to a set of
>native types in privileged languages is neither robust nor extensible.
>It seems to me that, on the model of validation of structured types, it
>is possible to define unstructured (simple) types by how they are
>validated, and that that definition is interoperable.
Pretty much agreed. I think that validation (specifying constraints on what an instance can
contain) and data binding (determining how to represent the textually-represented data in an
instance as bits within an application) are two separate tasks, and it doesn't make sense to try to
use the same language to do both. It especially doesn't make sense for the spec for the schema
language to contain a set of hard-wired "internal bits" types.
I'd rather see a separate "bind mapping" language that would allow one to give hints (or even
orders) for how to map various pieces of character-level data into internal structures in various
languages. I'm thinking in terms of a list of XPath expressions, each associated with a list of
language/application => type name pairs, something like:
<bindings>
<data match="//product/ID/@SKU">
<language name="Perl" binding="scalar"/>
<language name="C" binding="unsigned long"/>
</data>
</bindings>
A data binding application would use the bind mapping language to determine storage formats, and
the schema language to determine structural nesting and actual validation constraints on simple
types (that is, constraints imposed by the real-world problem domain, not by the number of bits
allocated for storage). Applications that don't involve data binding wouldn't need to use a bind
mapping processor.
|
