Cart
[Home] [By Thread] [By Date] [Recent Entries]
From: Michael Brennan <Michael_Brennan@a...> >I don't understand why this is a bad thing. XML established a standard >syntax for conveying structured information. Introducing additional syntaxes >just undermines the benefits of using a standard syntax, doesn't it? Look at almost any real markup language and you will see embedded notations are very common. In fact, I think it is a rule that humans like a change in syntax when there is a change in domains: XML is good for containers of unrelated data, but where one part of the data depends on another (e.g. composite) _and_ has a natural or common non-XML format, XML is not the notation of choice. It is bad for computers as well as humans, too. Because XML Schemas has not supported embedded notations, systems which require strong typing need to have data format converters (or home-made schema languages) on the creator end and/or the consumer end. So XML Schemas does not simplify life for people with data in other notations, it may positively _complicate_ it, by requiring other (as yet un-developed) specs at the front or back end. XForms is little help here, by the way, because it is only a particular application, not a general purpose layer for browsers. Whose interest does this serve? It is not the interests of someone who just wants to put either the simple $4000 or Rs3000 in a field. Or someone who wants to put a date 31/12/2001 in US style. They have to build other front ends: there are no standards for this, so they will use proprietary tools. If you are a bank, or builder of large computer-to-computer systems, it is fine. But if you are trying to build a small system for specific data, it gives you one more thing to think about. There is an easy way out of this: to allow regexes in XML Schemas to have subexpressions named (which Perl and OmniMark allow), and to present these as a little XML infoset which can be parsed. So "Rs30000" would be presented as <string><currency>Rs</currency><amount>30000</amount></result> Obviously there are lot of notations that are not convenient to express using regexes. URLs are notorious and Michael McQueen had his famous full-page regex for Gregorian dates published in his Journal of Markup Languages: Theory and Practise (which is well-worth subscribing to.) >But this is just an issue for presentation, isn't it? Having one standard >syntax for a data type simplifies implementation and reduces opportunities >for errors. Isn't it rightly the role of a "smart front end" to deal with >localization issues? Pushing that functionality into XML Schema would seem >to me to just add more complexity and blur the focus of what XML Schema >addresses. I'm not clear on why a data-centric standard like XML Schema >should tackle this issue, rather than something more geared toward binding >data to presentation (perhaps something like XForms?). No, it is not just presentation. Data stored in strings in databases will often be in some definite notation. XML's value is enhanced the more it can fit into existing systems, rather than forcing existing systems to fit it. That XML Schema 1.0 is a data-centric spec is itself a flaw, not something that should be pandered to by forcing unnessecary layers and processing. (And, let me hasten to add, it is a flaw that is not intrinsic to XML Schemas, so it can be rectified in future specs.) It should always be easier to send data which is in localized formats across the room than to send data in trans-national formats across the globe. Cheers Rick Jelliffe
|
