[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

characteristics of a good system
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

Please correct me if I have misinterpreted or over-simplified your remarks,
or injected my own ideas you don't agree with.


> 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


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.