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

Re: XML and "Federated" Data

• From: John Martin <John.Martin@n...>
• To: Chris Maden <crism@o...>
• 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?

Thanks,
John

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
> --
> <!NOTATION SGML.Geek PUBLIC "-//Anonymous//NOTATION SGML Geek//EN">
> <!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@i...
> 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@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...)

begin:vcard 
n:Martin;John 
tel;work:(919) 981-5394
x-mozilla-html:FALSE
org:State of North Carolina;Information Resource Management (IRM)
adr:;;;;;;
version:2.1
email;internet:john.martin@n...
title:Consultant
fn:John Martin
end:vcard

• Follow-Ups:
  • Re: XML and "Federated" Data
    • From: Chris Maden <crism@o...>

• References:
  • Re: XML and "Federated" Data
    • From: Chris Maden <crism@o...>

• Prev by Date: Re: XML and "Federated" Data
• Next by Date: Re: XML and "Federated" Data
• Previous by thread: Re: XML and "Federated" Data
• Next by thread: Re: XML and "Federated" Data
• Index(es):
  • Date
  • Thread