[
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
documents.)
>[ 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
information.
Simon St.Laurent
"Every day in every way I'm getting better and better." - Emile Coue
|
