[
Lists Home |
Date Index |
Thread Index
]
From: "Amelia A.Lewis" <amyzing@talsever.com>
> AndrewWatt2000@aol.com 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
|
