[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 system for XML
From: "Amelia A.Lewis" <amyzing@t...> > AndrewWatt2000@a... wrote: > > What characteristics would a good type system for XML have? > > Slogan version: complete, consistent, comprehensible. Hi Amelia, I _think_ I agree with every point you have made, and I apologize for trying to boil down your complex ideas into a few bullet points, but these seem to me to be the nucleus of your criticism/proposal: - A type system should be based on a small number of primitive types (much smaller than those in XML Schema Datatypes) , and all other types should be defined in terms of these. -A type system should be extensible, but more than that, there should be ways to introduce new type systems (for simple types). - The ways that types can be extended should not be limited to a few predefined parameters, e.g., the facets in XML Schema. A type system should be able to define its own parameters. - A type system should provide, for each type it produces, a function to answer true or false if a given string is valid, a function to translate a string into an instance of the type defined in terms of the primitive types mentioned above, and a function to translate an instance of the type to a string. Please correct me if I have misinterpreted or over-simplified your remarks, or injected my own ideas you don't agree with. Bob > 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
|