Re: [ubl-comment] Schema type generation and type reuse question

[Chin Chee-Kai <cheekai@softml.net>]

I think I agree with what your pointing out about the "loosing
of connection" between similar and exact types.  As a reference,
the id values you listed are found in "UBL_Library_Op70_Reusable.xsd".

The way I see it is that there are 2 things at work at the
same time: Definition of structure field names ("Default UBL Name")
and the definition of data type for the fields.  The latter
appears to be a clever use of 4 columns
   ("Object Class Qualifier" + "Object Class") .
         ("Property Qualifier" + "Property Term")
the entirety of which defines the data type.

In the definition phase (ie, the first time a new data type is 
defined (e.g. AddressType)), there is no "Object Class Qualifier"
and the data type names are defined the same as data field names
(except only for "Identification" which is remapped to "ID").

Subsequently (e.g. DeliverToAddressType), it extends, or rather
re-uses, the definition of AddressType by having the same values
for "Object Class" throughout all the fieldnames that are to be
defined within DeliverToAddressType, but this time having a new
"Object Class Qualifier" value as "Deliver To".   Same for 
"JurisdictionAddressType".

For interpretation (ie. program processing), if there is consistent 
use of "Object Class Qualifier" to mean only that the usage area
is different but the meaning given by 
("Object Class").("Property Qualifier" + "Property Term")   ---(2)
remains the same, then the "link-back" as you brought up can
be resolved by tracing back via (2).

I mentioned "if" as that is just my interpretation from looking
at the files.  Someone might want to confirm or differ from this.

That said, for "Default UBL Name" column, there're many spurious
spaces (eg. "Postal Zone"), dashes (e.g. "Country Sub-entity),
and even apostrophes (e.g. "Buyer'sID")  that strictly speaking
are not proper XML local names.  Dashes are ok to be used in
XML, but I find it strange-looking among all the otherwise
CamelCased alphabetic names.


cheers,
Chin Chee-Ka
SoftML





On Tue, 25 Feb 2003, Danny Vint wrote:

>>
>>In reviewing the Schemas that were generated I was surprised to see the
>>redefinition of complexTypes for the various address and party types. For
>>instance:
>>
>>	<xsd:element name="Address" type="AddressType"/>
>>	<xsd:complexType name="AddressType" id="UBL000028">
>>
>>	<xsd:element name="DeliverToAddress" type="DeliverToAddressType"/>
>>	<xsd:complexType name="DeliverToAddressType" id="UBL000145">
>>
>>	<xsd:element name="JurisdictionAddress" type="JurisdictionAddressType"/>
>>	<xsd:complexType name="JurisdictionAddressType" id="UBL000309">
>>
>>	and there are others.
>>
>>It seems that the only thing that really changes is the description of
>>elements in the different aggregates, but from what I see the "address"
>>content stays the same. I would have expected to see something like this:
>>
>>	<xsd:element name="Address" type="AddressType"/>
>>	<xsd:complexType name="AddressType" id="UBL000028">
>>
>>	<xsd:element name="DeliverToAddress" type="AddressType"  id="UBL000145"/>
>>
>>	<xsd:element name="JurisdictionAddress" type="AddressType" id="UBL000309"/>
>>
>>Was the previous sample what was really intended to be generated as the
>>final schema? I see how it helps in the mapping of the definitions of all
>>the various types of address, but it really complicates the final
>>implementation when you have (in my sample) 3 different definitions of the
>>same complexType, rather than reuse or extension of the basic AddressType.
>>
>>With this schema I loose the connection between these similar/exact types,
>>just to maintain documentation and mapping back to the spreadsheet. Maybe
>>the complexType definition of AddressType could gather all the
>>documentation together with something that indicates, when part of
>>JurisdictionAddress, this means, X, and when part of DeliverToAddress this
>>means Y.
>>
>>Comments?
>>
>>..dan
>>-------------------------------------------------------
>>Danny Vint
>>ACORD                         1 Blue Hill Plaza
>>                                 PO Box 1529
>>dvint@acord.org                 Pearl River, NY 10965
>>http://www.acord.org
>>
>>Voice:510:522-4703
>>FAX: 801-749-3229
>>
>>
>>----------------------------------------------------------------
>>To subscribe or unsubscribe from this elist use the subscription
>>manager: <http://lists.oasis-open.org/ob/adm.pl>
>>