[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Why XML data typing is hard (was Re: Internal subset equivalent in new s

• From: <david@m...>
• To: <xml-dev@i...>
• Date: Fri, 27 Nov 1998 07:07:02 -0500 (EST)

Ketil Z Malde writes:

 > What could be useful and relatively simple, is a restriction of the
 > *form* of the data, e.g. forcing the <name type="city"> to contain
 > only letters and start with a capital, or LC subjects to be two upper
 > case letters (if that's what they are).  Phone numbers, dates, sort
 > keys, there are many cases where it would be helpful to have the
 > parser catch these things, I think.

Ketil is writing from Norway, so he has probably already had some
(unpleasant) experiences with L10N issues in software coming from
North America.  Read on...

Imagine that someone sent an expensive XML-based system from North
America to Norway, and you discovered that the system constrained
phone numbers to consist of exactly 10 digits (XXX XXX-XXXX): you
would be quite right to demand a quick fix or a refund.  Now, imagine
that someone sent an XML-based system from Norway to Beijing, and it
constrained city names to contain only Roman letters (accented and
unaccented); in fact, you don't need to go so far -- even the good
people of Long Beach and the nuns of Sainte-Marie-d'en-Haut need
spaces, apostrophes, and dashes as well as Roman characters in their
place names.

I'm not suggesting that a set of simple XML data-typing constraints
cannot be helpful -- if you're building a database only of Norwegian
city names, you know that you don't have to deal with Han or Kanji
(unless, of course, you do such a good job that you decide to
commercialise your system) -- but coming up with data-type constraints
that both useful and generalised enough for all XML users across all
of the major Locales and all of the Unicode character repetoire is
*very* difficult.


All the best,


David

-- 
David Megginson                 david@m...
           http://www.megginson.com/

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)

• Follow-Ups:
  • Re: Why XML data typing is hard (was Re: Internal subset equivalent in new schema proposals?)
    • From: len bullard <cbullard@h...>
  • Re: Why XML data typing is hard (was Re: Internal subset equivalent in new schema proposals?)
    • From: Murray Maloney <murray@m...>
  • Re: Why XML data typing is hard (was Re: Internal subset equivalent in new schema proposals?)
    • From: Ketil Z Malde <ketil@i...>

• References:
  • Re: Internal subset equivalent in new schema proposals?
    • From: "Michael Kay" <M.H.Kay@e...>
  • Re: Internal subset equivalent in new schema proposals?
    • From: <david@m...>
  • Re: Internal subset equivalent in new schema proposals?
    • From: Ketil Z Malde <ketil@i...>

• Prev by Date: Computer Weekly
• Next by Date: Re: Why XML data typing is hard (was Re: Internal subset equivalent in new schema proposals?)
• Previous by thread: Re: Internal subset equivalent in new schema proposals?
• Next by thread: Re: Why XML data typing is hard (was Re: Internal subset equivalent in new schema proposals?)
• Index(es):
  • Date
  • Thread