[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [wsrp-wsia] [I#182] Globalize the Address Type/User Informationfields and Postal Code is missing.
I have spent some time examining the various items pointed at relative to
globalization of name and address information. The tables in the attached
document reflect my understanding from those specs that define schemas for
this information appearing in xml documents.
My current thoughts are to stay aligned with P3P for v1, reasons include:
- None of the definitions are well established yet.
- P3P is the simplest definition.
- If v2 wants to add the complexity of the fully internationalized specs,
a couple of straight forward possibilities are:
1. Have the message use the xsi:schemaLocation attribute to say what
standard is being used for the included data.
2. Have the Producer's metadata say what standards it supports & the
Consumer's registration say what standard it will use. All user
information is then in the specified format.
- The extensions elements could carry data P3P did not account for in v1.
I'm not sure where the deviations from P3P came from, they include:
- street is an array (probably was from my experience in our projects)
- nickname is camel cased (probably was a typo on my part)
- postalcode is missing
- organization was truncated to org
There may be deviations in the other structures as well ....
Since P3P did not publish a schema for their structures, this choice means
producing our own definition that reuses the P3P field names and
semantics. This is close to the original intent, my suggestion is just to
eliminate deviations in order to make reuse of other specs the design goal
in this area.
Rich Thompson
Rich Thompson/Watson/IBM@IBMUS
11/26/2002 10:22 AM
To: wsrp-wsia@lists.oasis-open.org
cc: Martin Bryan <mtbryan@sgml.u-net.com>
Subject: [wsrp-wsia] Internalization of Name and Address
structures
This needs its own thread ....
At this point I see the following pointers for examination:
- xAL 2.0 (extensible Address Language) [OASIS Customer Information
Quality TC]
- xNL 2.0 (extensible Name Language) [OASIS Customer Information Quality
TC]
- HR-XML Consortium's personName_1.2 and postalAddress_1.2
- XNSORG/OneName's XNS-1.0 spec
- OASIS UBL
- http://xml.coverpages.org/namesAndAddresses.html "Markup Languages for
Names and Addresses"
- http://xml.coverpages.org/adis.html "Address Data Interchange
Specification (ADIS)"
- Universal Postal Union (UPU) Standards Board
Others?
Rex Brooks
<rexb@starbourne. To: Rich
Thompson/Watson/IBM@IBMUS, Martin Bryan
com> <mtbryan@sgml.u-net.com>
cc:
wsrp-wsia@lists.oasis-open.org, rkumar@msi.com.au
11/26/2002 08:48 Subject: Re: [wsrp-wsia]
Roles
AM
Hi Rich, Martin, Everyone,
In the Human Markup Language XML Primary Base Schema/Specification
1.0 our TC approved for public comment at the start of November, we
declared the xAL 2.0 (extensible Address Language) and the xNL 2.0
(extensible Name Language) schemata of the OASIS Customer Information
Quality TC, and imported the HR-XML Consortium's personName_1.2 and
postalAddress_1.2 schemata as well as XNSORG/OneName's XNS-1.0 specs
for the purpose of making our specification interoperable with these
specifications, the imported namespaces are commented out for now
because those organizations have urn/schemaLocation concerns under
consideration, but which are scheduled for minor revisions in those
areas shortly after the start of the year. It is likely that we will
also import or declare XLIFF as well.
Is it possible to simply make role fields optional?
Ciao,
Rex
At 7:51 AM -0500 11/26/02, Rich Thompson wrote:
>I have had the uneasy feeling about roles for a while, but rewriting
those
>sections finally caused me to focus on it enough to see the detailed
>reasons why (you site some good examples). At this point I think it is
only
>useful to that set of Consumer-Producer pairs that have a coordinated set
>of roles and since we won't be able to define tight semantics it doesn't
>belong in the spec.
>
>On the address side, the variations in address are a big issue and WSRP
is
>not the right place to tackle it. We took guidance from the P3P data
model
>in this area though we did need to provide some structure for their
>unstructured portions. I was hoping much of the variability could go into
>the field named street as this is an array of strings. In addition, each
of
>the structures is individually extensible with the expectation that some
of
>those extensions will come back for consideration as base level fields in
>v2. If there are other sources that would give a more internationalized
>view of this area, we certainly would appreciate a pointer ....
>
>
>
>
>
> "Martin
>Bryan"
> <mtbryan@sgml.u-n To: Rich
>Thompson/Watson/IBM@IBMUS
> et.com>
>cc:
> Subject: Re:
>[wsrp][wsia] Draft spec v0.85
> 11/25/2002
>11:35
>
>AM
>
>
>
>
>
>
>
>
>Rich
>
>> Reflecting on this further, the whole schema of role mapping only
really
>> works when there is a huge overlap in the roles supported at the
Producer
>> and the Consumer. To me this is more and more smelling like something
>that
>> belongs as an extension rather than an inherent part of the spec.
>
>At last you are beginning to see the problem. Now consider what happens
if
>the Producer is Finnish and the Consumer is Japanese and both use their
own
>languages to define their services. Now we have a real problem, which
will
>only be solved if you introduce a multilingual ontology of mapped terms
>into
>the equation.
>
>The real problem, however, is how to do this dynamically, so that we can
>annotate recorded roles with "related names from other sources" (e.g.
>record
>that someone has determined, by some off-line means, that A relates to
B).
>
>Incidentally your address info structure in section 10 has not been
>suitably
>internationalized. You need techniques for defining subsections of what
you
>call cities (e.g. Kensington, London) and for identifying blocks (both at
>street and house level) and subunits of buildings (flats or suites). For
>example, I have a friend in Roumania for whose address I need to identify
>the flat number, the staircase, the block on the road (unless you call
>Block
>26 a name!) and the district of the town in addition to the fields you
>allow
>me to define once only if I want to send him something. It looks like I'm
>going to have to define more extensions than you do base fields, even
>though
>every different Consume and Producer will have to define his own set of
>extensions for most of these :-(
>
>Martin Bryan
>The SGML Centre, 29 Oldbury Orchard, Churchdown, Glos GL3 2PU, UK
>Phone/Fax: +44 1452 714029 E-mail: mtbryan@sgml.u-net.com
>
>For further details about The SGML Centre visit http://www.sgml.u-net.com
>
>
>
>
>
>
>
>
>
>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>
--
Rex Brooks
Starbourne Communications Design
1361-A Addison, Berkeley, CA 94702 *510-849-2309
http://www.starbourne.com * rexb@starbourne.com
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
Attachment:
Internationalization.doc
Description: Binary data
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC