OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: A query in xml schema..

> From: Rick Jelliffe [mailto:ricko@allette.com.au]
> Sent: Monday, May 07, 2001 7:46 AM
> To: xml-dev@lists.xml.org
> Subject: Re: A query in xml schema..
> [...]
> XML Schemas 1.0 excluded support for composite data types 
> (notations, which
> need
> "microparsing") or localized lexical forms.  It wants elements and
> attributes to be
> used to delimit different parts of data.

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?

> The more that people say "this is unacceptable", the greater 
> the chances
> that it may
> be dealt with in XML Schemas 1.1, and not in XML Schemas 2.0, 
> I suppose.  In
> my
> view, it is a serious ommission that means that XML Schemas, 
> in effect,
> requires a smart front end to convert from human-friendly 
> notations for
> currency (and dates) into
> space-delimited tokenized forms.

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?).