RE:

-----Original Message-----
From: John McClure [mailto:hypergrove@olympus.net]
Sent: Wednesday, 3 October 2001 5:17 AM
To: rkumar@msi.com.au
Cc: Todd Boyle; Gabe Minton; Jeff Fisher; Mike Young; vincent.buller@and.com
Subject:

Mr. Kumar,
Attached is a document containing examples of Data Consortium Namespace (DCN) encoding for addresses. Your technical committee is concerned with addresses, so I thought you might have feedback about our approach, since we are using a "dotted-tag". This document contains the DCN's encoding for samples that were posted on your website prior to your current specification (which has many more samples). The DCN's approach is one that appears less complicated than what the technical committee has now published, but I know already that some functional diferences do exist when comparing the two. However, the DCN approach appears less complicated in part because of our use of a "dotted-tag" means that much less element nesting occurs. (In the Data Consortium, we have found that useability of a schema increases as nesting is reduced. Our encoding seems to be "about right" for the needs of Data Consortium members. You might have a wholly different opinion though.)

A "dotted-tag" is one that combines two adjacent tags, separating them by a 'period' -- it's handy because two adjacent nouns often are adequate to imply a connecting verb, and therefore DCN datastreams can conform to the Resource Description Framework (RDF) in an automated way. However, it also means that a pre-processor needs to convert a datastream into a fixed representation for querying by XSL stylesheets, because the way that dotted tags are encoded is entirely under the control of the publisher - adjacent tags are meant to be arbitrarily combined by the publisher. In the DC, we define these 'dotted-tags' in a specification for what we call "XScript". Basically, XScript is an ECMA-compliant front-end to XML-encoded datastreams, thus insulating Data Consortium members from changes in the encoding of those streams.

What's here is not the entire DCN picture, since our implementation of the standards for secondary address types as defined by the US Postal Service (e.g., basement apartments) is not readily apparent. To support secondary address types, we define appropriate object classes in our dictionary, and then weave those classes into the content models defined by our XScript specification.

Feel free to redistribute this information to your mailing list. I hope you find this helpful to your work, and we look forward to your comments and suggestions.
Thanks,
John McClure

Hypergrove Engineering
211 Taylor Street, Suite 32-A
Port Townsend, WA 98368
360-379-3838 (land)

For a discussion group about the Data Consortium Namespace, please
http://groups.yahoo.com/group/DCNArchitecture/join

ciq message