[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: What are the characteristics of a good type systemfor XML?
On Mon, 12 May 2003 16:19:13 EDT AndrewWatt2000@a... 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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|