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


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] W3C Schema: Resistance is Futile, says Don Box

[ Lists Home | Date Index | Thread Index ]

At 09:28 AM 6/11/2002 -0600, Matt Gushee wrote:
>I come from the expectation of having appropriate tools for different
>types of users. Personally, I do most of my work in vi and have no
>problem looking up and remembering the correct syntax for dates or
>whatever. But if the user is not a developer and has no interest in the
>code underlying their application, well, why shouldn't they be able to
>enter a date in the way that is natural for them, and let the
>application normalize it?

I come from the expectation that documents should remain as accessible to 
their authors as possible all the way up to the application that munges 
them.  I spent a lot of years with HTML developers who found their way to 
the source code even when they used tools as their primary input/edit 
process, so I don't have much patience for tools that make substantial 
changes between input and storage.

> > It's downright nonsensical if you come to XML from a more hands-on 
> approach
> > where encountering markup on a regular basis is part of the fun, or where
> > conversion from existing documents is a critical part of the job
> > description.
>Why would somebody who can't deal with date formats want to do that sort
>of work?

It's not a matter of "can't deal with date formats".  It's a matter of 
respecting the original information and being capable of dealing with it as 
presented.  Not everyone is thrilled with normalization to ISO 8601 
Gregorian calendars.

(For a delightfully complex case, ask any pre-20th century historian about 
Julian dates and computers and comparisons between dates in different 
countries and what that does to things like representations of original 

>[ Hmm ... technical writers may be an interesting borderline case ...
>   but I think their numbers pale in comparison to those who are either
>   clearly coders or clearly not coders ]

I think the coder/not-coder distinction is much blurrier than that, though 
it may be an artifact of my coming here from HTML.  Numbers may pale, but 
possibilities don't.

>See, Bryan was suggesting that there is a problem with requiring dates
>*in XML* to conform to a certain datatype or pattern.

I think I agree with Bryan.  XML is text, not magically typed tokens.

>  If the schema
>language or an individual schema required some cryptic, proprietary
>format I would agree. But any educated person can *understand*
>'2002-06-11' without too much effort.

I dunno.  Is that June 11 or November 6?  A normalization that makes sense 
to your kind of educated person may not make sense to mine.

>  The question I was addressing,
>which I think was Bryan's point, was whether they should have to
>remember how to type it. And in my view the answer to that question, and
>the appropriate choice of tools, depend on what kind of user they are,
>and neither has anything to do with whether schema datatypes are good
>or necessary.

It has everything to do with whether normalization is good or 
necessary.  As W3C XML Schema enforces normalization, those types are also 
polluted by this for purposes of this conversation.

>By the way, Simon, I've followed your writings for some time, and I
>suspect you have a problem with the rigid division of labor between
>developers/managers/peons etc. If so, I'm very much with you on a
>philosophical level. For better or worse, I'm a bit more willing to
>compromise with the ugly realities of 21st-century society.

I'm glad to hear it, but I think your vision of compromise here is my 
vision of surrender, with ugly consequences for any notion of localized 

Simon St.Laurent
"Every day in every way I'm getting better and better." - Emile Coue


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS