[
Lists Home |
Date Index |
Thread Index
]
- From: Rick JELLIFFE <ricko@geotempo.com>
- To: xml-dev@xml.org
- Date: Sun, 07 May 2000 19:09:09 +0800
"Stephen T. Mohr" wrote:
> I think you're confusing the role of the XML processor and the application
> built on top of it. You've typed the element as "number" but included
> string information. This relies on an implicit mapping to a string, which
> is properly the role of the application.
I don't think it is easy as this.
XML Schemas standardizes a set of basic datatypes, and allows various
constraining mechanisms on them, for example lexical constraints.
But it does not really allow new basic datatypes nor datatype with
completely different lexical spaces. (Actually, because of the
annotation element, you can just declare some type to be a string and
then put in your own home-made datatyping system; but this is outside
the framework not an extension of the basic infrastructure provided.)
All this is fine if we start from the basic model of XML Schemas as
being for data exchange from databases or internationalized languages
such as Java, where the end-points are thick enough to convert into the
appropriate localized form.
But this is not the case for all markup languages. It is quite possible
that I want to have a markup language with data in a localized format
(e.g., 12/20/1999 as used in USA) where I would like to be able to say
"this data is a year".
IMHO, this is an issue of notations: XML Schemas does not gives us
notations (i.e., mappings from arbitrary lexical spaces to datatypes),
it only gives us a fixed set of contstrainable notations and calles them
datatypes.
Is this good enough? That is something that I think developers should
consider strongly over the next period, while XML Schemas is a "Candiate
Recommendation". I am sure the XML Schema WG will be very interested in
thoughful comments in this regard; I think comments from various members
have shown that, unlike nasty opinion to the contrary, the WG is keen
that XML Schemas has the right feature set to meet real public needs. In
this particular case, there are persistent calls; as I mentioned above,
I think this may be that there is an expectation or architecture gap in
how schemas fit into XML that is the culprit:
Is a good schema language one which lets me describe data that conforms
to the simple
datatypes used in big vendor's products and/or that is described in
international
standards, or is a good schema language one which lets me describe my
data in whichever
form I have chosen to have it in?
Personally, I would prefer a schema language to err towards the latter
rather than the former. Comments?
Rick Jelliffe
(Writing entirely privately)
***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************
|