[
Lists Home |
Date Index |
Thread Index
]
On Mon, 12 May 2003 16:19:13 EDT
AndrewWatt2000@aol.com wrote:
> I guess it is fairly easy to complain about the deficiencies of W3C
> XML Schema datatypes.
>
> What characteristics would a good type system for XML have?
Hmm. You liked the song so much that you want an encore? Or you don't
like my inability to carry a tune and so don't listen? *laugh*
Slogan version: complete, consistent, comprehensible.
Definition list version:
Complete: the system must be able to represent the types that XML
authors want to use. It should not privilege certain use cases over
others without providing an escape to allow XML processors to change the
privileges. That is, it should provide a mechanism for defining new
"primitive" types.
Consistent: the system must be rules based. The rules must logically
follow one another. A good start might be to restrict the
characterization of types to that relevant to XML (that is, to the realm
of data transmission and storage, excluding data manipulation). (I also
think that a good start is to make xmlstring the ur-type, such that all
"primitive" types are constrained from that starting point; clearly a
debatable position)
Comprehensible: the system must be amenable to short explanation. If it
takes more than half an hour, a whiteboard, and audience of greater than
average attention and intelligence, then it isn't comprehensible.
I suppose I could provide a still-more-detailed version, but I'd rather
pursue my own agenda (is that full disclosure, or the magician's wave
distracting attention?).
From my perspective: the base type is xmlstring, a sequence of a subset
of unicode characters (excluding C1, C0 except HT CR LF, the character
'<', and the character '&' except as the start of an escape sequence).
Base type validation is equivalent to well-formedness checking for text
nodes, then. The rules for defining a "primitive" type (which further
constrains the valid lexical space defined by xmlstring) is to define
the algorithm used for validation. A primitive type definition SHOULD
also include the algorithm preferred for comparison/collation (or
possibly a choice of algorithms).
This gives enough to define type libraries, RNG style, and to do some
basic work on the types defined (to sort, that is).
The further definition of types defines permitted operations on two
instances of the same type and what each operation does, and coercion of
one type to another. I would suggest that both of these areas are out
of scope for pure-XML type definition (though clearly of interest to
something like XQuery, and arguably of interest to XPath and XSLT).
This suggests that it might be nice to have a pluggable model for types
in XPath, XSLT, and XQuery, since the definition of "completeness"
implies that a simple authoritative list ("Types that Amy thinks are
Important enough to Include"; substitute random authoritative body for
'Amy' and see if it makes you feel better) is not the best solution. If
your list doesn't include provision for the geographical location types
that Simon needs, expect Simon to ignore your types, whether system or
collection. Multiply by all the people interested in areas that aren't
on your radar.
I would suggest that a standard set of derivations (similar to, but
perhaps a little more systematic than W3C XML Schema's 'facets'), and a
standard set of combinators (please more than the extremely weak 'list'
defined by W3C XML Schema) would also be important, so that primitive
types may become derived types. Or perhaps the system would just define
how derivation and combination algorithms may be published and
identified.
Note: this set of requirements is radically different from the
requirements that the W3C XML Schema working group operated under. They
had to support DTD types. No such requirement here. It'll get defined
if it's important. They had to support types common in common
programming languages and in common non-XML data storage formats. No
such requirement here. It'll get defined if it's important, and the
mapping will be up to the users of the language or the folks writing the
bridge to the non-XML format. The requirements here are complete[able],
consistent, comprehensible. They give a possibility of a long-term
solution, and if implemented in a way that allows real completeness
(which implies that almost anyone can publish a type library, and the
alleged invisible hand of the "market" will straighten it out), provide
a means to *discover* a standard before setting it in stone.
Amy!
--
Amelia A. Lewis amyzing {at} talsever.com
The less I seek my source for some definitive, the closer I am to fine.
-- Indigo Girls
|
