[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Objections to / uses of PSVI?
"Simon St.Laurent" wrote: > > I disagree. I think they have thought through what they want to do. > > I think you must hang out with a wiser crowd than I do. Hmmm. Let's see. There's me, and my 1 year old daughter, and a whole lot of stuffed animals in varying states of chewed-on-ness, ... ;) > > They > > want, for example, to be able to validate that a quantity is a (string > > representing an) integer and not "abc". This strikes me as perfectly > > reasonable. > > For validation only, fine. I don't mind checking that something's an > integer. Where I think they lack imagination is their insistence that > because it _is_ an integer in XYZ language, it _is_ an integer in > markup. Then the markup technologies have to deal with such notions, > and suddenly things look very different. But I'm not looking at something as an integer in XYZ language. That's what leads to data types like int, short, and long. I'm looking at something as an integer in the real world. When I count my fingers, I get an integer. When I measure the length of my toes, I get a float. When I shuffle through the coins in my pocket, I get a two-place decimal. This has nothing to do with programming languages -- this is what the data actually is and it seems entirely appropriate to markup. One of the ugly realities that has come out of data integration research is that there are a whole lot of assumptions about data that can't be determined by a machine looking at an element type or attribute name. For example, if I send you an invoice that includes the markup: <Total>1234</Total> how much money in real (US) dollars are you going to send me? How to interpret the value 1234 needs to be somewhere. You can put it explicitly in markup, you can put it in a schema, or you can put it in a specification that may or may not be visible to the recipient of the document. The first two are machine-processable; the third is not. Data types are useful. > Think about retrofitting the DOM or especially SAX to represent the > PSVI, and that difference is pretty plain. I'm pretty convinced that the current PSVI is not the way to go. It confuses defaults with types with validation, depends on XML Schemas for its typing model, and, once you force people to support the XML Schema data model, is too onerous on implementers. I'm less convinced that some sort of typing information -- especially simple types -- isn't warranted. One thing I'm not clear on is whether that typing information belongs in a schema or in an augmented instance document. I like the idea of metadata-driven applications, but all the ones I can think of run off schemas rather than type information in instance documents. (For example, I've never written a query processor, but it seems reasonable to keep type information separate from instance data when compiling and optimizing a query. Or is the problem that, in a semi-structured world, this isn't possible?) That's one reason that I asked how people intended to use the PSVI. I find it interesting that the answer has, so far, been silence. > > I think where the XML Schemas data types have missed the boat is in > > their degree of complexity, as Amy Lewis points out. If you want > > interoperability, you can't go much beyond saying that a number is an > > integer. It is the up to the recipient of the document to decide (a) > > whether they can represent that number in whatever language / system > > they are using and (b) what data type they choose to represent it in. > > "It is up to the recipient" is fine by me - but that's not what I hear > discussed in ~90% of discussions of XML typing and schemas outside of > this list. Agreed, although I'm not convinced that means we should throw out types altogether. -- Ron
|
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
|