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


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: XML and "Federated" Data

[ Lists Home | Date Index | Thread Index ]
  • From: John Martin <John.Martin@ncmail.net>
  • To: Chris Maden <crism@oreilly.com>
  • Date: Fri, 06 Aug 1999 11:44:08 -0400

Hi Chris,
   Thanks for your response.  Just to steer this discussion (if there is one) in the right
direction, I am not interested in debating all the element considerations to make (we've
discussed ad nauseam things like zip code vs. postal code, should it consider international,
what if the USPS standard changes, shouldn't it be alphanumeric instead of numeric since we're
not calculating on it, etc.).  What I'm really trying to find out is if XML might enable us to
totally avoid doing this work at all, and isn't the idea of "federating" XML tags unnecessary?


Chris Maden wrote:

> [John Martin]
> > Data Element/Attribute Name:  Zip Code
> > Element Definition: As defined by USPS: The address element that
> > identifies a geographic region or specific location defined by the
> > postal service within the US.
> > Valid values: USPS Table
> > Element Format: 5N
> > Element Length: 5 Bytes
> > Element Type: Numeric
> What about 9- or 14-digit zip codes?  What about foreign customers
> with their own postal code notations?
> I think a better approach is to define a "postal code" element or
> attribute, and use application validation to check for a number of
> possible legal values; for US addresses, it must be 5, 5-4, or 5-9 (I
> think) syntax; for Britain and Canada, I believe the syntax is 3 3
> with numbers or letters (9X9 X9X maybe?).  You could also, if they're
> few enough, just not attempt to automate validation of non-US postal
> codes.
> The federation effort is going to be as difficult, or more so, than
> any other document or database analysis effort.  Don't get in the way
> of future expansion.  (A friend working on a prison database system
> tells me they have six values for gender.)  That goes two ways: if you
> start with a tight definition, you can loosen it later and old
> documents still comply.  But if the validation is done in software,
> then newer documents may be rejected by older systems; if that's what
> you want, then that's fine, but it may be better to start loose and
> tighten down later.
> -Chris
> --
> <!ENTITY crism PUBLIC "-//O'Reilly//NONSGML Christopher R. Maden//EN"
> "<URL>http://www.oreilly.com/people/staff/crism/ <TEL>+1.617.499.7487
> <USMAIL>90 Sherman Street, Cambridge, MA 02140 USA" NDATA SGML.Geek>
> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
> Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
> To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
> (un)subscribe xml-dev
> To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
> subscribe xml-dev-digest
> List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)
tel;work:(919) 981-5394
org:State of North Carolina;Information Resource Management (IRM)
fn:John Martin


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

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