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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ciq message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: few more thoughts


Further thought:

We have to be careful in defining "mandatory" fields as it puts lot of
restrictions on the end users. Here the role of xNAL is not to define 
how an address structure should be, it is intended to be a language
that can adopt to different address representations that exist in customer
databases that enables interchange of data across platforms, tools 
and products. xNAL is for data interchangeability and not for defining
a global name and address structure in XML. 

For example, an organisation might not have stored postcode as part 
of its data. In such a case, if they use xNAL, they will be forced to fill 
in postcode that does not exist if xNAL makes postcode mandatory. 

Mandatory fields  will be important in cases where one prefers to
go for a detailed level. For example, let us take the following
example:

23 Archer Street
Boulder, CO 12345-1234

At a higher level, the representation in XML will be:

<street>23 Archer Street</street>
<locality>Boulder</locality>
<state>Co</state>
<postcode>12345-5678</postcode>

But, if the user wants to use a detailed level of representation for
postcode so that it is:

<postcodedetails>
 <postcode>12345</postcode>
 <extendedpostcode>5678</extendedpostcode>
</postcode>

then postcode and extendedpostcode becomes mandatory fields under
the postcodedetails tag of xNAL. 

Cheers

Ram


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC