[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A query in xml schema..
- From: Rick Jelliffe <firstname.lastname@example.org>
- To: email@example.com
- Date: Tue, 08 May 2001 13:29:02 +0800
From: Michael Brennan <Michael_Brennan@allegis.com>
>I don't understand why this is a bad thing. XML established a standard
>syntax for conveying structured information. Introducing additional
>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
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)
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
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
a little XML infoset which can be parsed.
So "Rs30000" would be presented as
Obviously there are lot of notations that are not convenient to express
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
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
should be pandered to by forcing unnessecary layers and processing. (And,
me hasten to add, it is a flaw that is not intrinsic to XML Schemas, so it
be rectified in future specs.)
It should always be easier to send data which is in localized formats across
than to send data in trans-national formats across the globe.