[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: alternate enums in XML Schema
"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@x...&BODY=unsubscribe%20xml-dev List archives are available at http://xml.org/archives/xml-dev/ ***************************************************************************
|
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
|