OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] What are the characteristics of a good type system for XML

[ Lists Home | Date Index | Thread Index ]

Hey, Bob,

On Mon, May 12, 2003 at 11:41:23PM -0500, Bob Foster wrote:
>From: "Amelia A.Lewis" <amyzing@talsever.com>
>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:

Hmm.  Well, maybe some corrections in emphasis, as regards your summary.

>- 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.

Err.  I have said that in the past.  I've reconsidered, though.  I would say
that the type system must define the rules for creating and publishing
primitive types.  Then let the authors and users and implementors of XML
decide which of those are interesting and useful.  This also means that
private agreements can adopt less "universal" types that happen to be well
suited to their particular domain.

>-A type system should be extensible, but more than that, there should be
>ways to introduce new type systems (for simple types).

Agreed.

>- 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.

I think we're on the same page.  Apart from defining how to define new
primitive types, the system ought to also define how to define derivation
and composition algorithms.

>- A type system should provide, for each type it produces, a function to
>answer true or false if a given string is valid,

Yes.

> a function to translate a
>string into an instance of the type defined in terms of the primitive types
>mentioned above,

err, no.  I think that's outside the scope of XML.  It might possibly be
useful, but you can't really predict, sitting inside the XML world, what the
type system you're mapping onto looks like, or how the transform is going to
work.  Supposing that a library defines a "date" type, how can it reasonably
define the transformation to an instance of that type in Java, C++, Python,
Haskell, and Perl as a single function?

> and a function to translate an instance of the type to a
>string.

Err.  Well, it *is* a string.  In XML.

Also, you've left out sorting.

I would say, so far as functions go:

For the type gronk:

Given a string, the gronk type specification allows you to determine if this
is a representation of a valid instance of type gronk.

boolean gronk(xmlstring);

Given two strings known to be of type gronk (see preceding function), return
-1 0 1 to indicate whether the first is smaller than, equal to, or larger
than the second (an equality function, plus a bit).

[-1,0,1] gronkSort(xmlstring, xmlstring);

Does that help?

Amy!
-- 
Amelia A. Lewis                    amyzing {at} talsever.com
    Merchant, street girl, beggar, yeoman,
    king or common, man or woman,
    only two things make us human--
    sorrow and love, sorrow and love ....
                -- The Last Song of Sirit Byar




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS