Re: A query in xml schema..

[Rick Jelliffe <ricko@allette.com.au>]

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
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