Re: [ubl-hisc] SBS and input specs

["Stephen Green" <stephen_green@bristol-city.gov.uk>]

Ken wrote:

> Steve, can I assume 
> that every attribute is uniquely named across the set of all attributes, 
> regardless of the namespace in which they are declared?).  Before I 
> undertake any changes, are there other issues?

To quote the NDR, it states:

"[ATN1] Each CCT:SupplementaryComponent xsd:attribute "name" MUST be 
the Dictionary Entry Name object class, property term and representation term 
of the ccts:SupplementaryComponent with the separators removed. 
Example: 
ccts:SupplementaryComponent ubl:attribute
Amount Currency.Identifier amountCurrencyID
Amount Currency. Code List
Version.Identifier
amountCurrencyCodeListVersionID
Measure Unit.Code measureUnitCode
UBL currently truncates the ccts:SupplementaryComponent xsd:attribute 
name. Specifically, if the object class of the ccts:SupplementaryComponent is the 
same as the object class of ccts:CoreComponentType or Datatype to which it relates, 
then the object class term is dropped from the xsd:attribute name. 
Example: 

ccts:SupplementaryComponent ubl:attribute
Code. Name name"



This means that two attributes may have the same name but be in different
namespaces since a cct:CodeType may have an attribute 'name' but so may
a udt:CodeType and so may a specific codelist Schema CodeType and, due to
name shortening which sometimes removes the 'object class term', so may
any other ..Type in any other namespace.

Now that is how it stands in UBL 1.0 but who is to say it may not change for UBL 2.0
or even for UBL 1.x

So I guess we can't assume much here. Sorry :-(

On the other hand it is likely but not without the possibility of an exception
that 'name' as an attribute in one element will carry the same semantic meaning
as an attribute 'name' elsewhere. The NDR at present states:

"4. Naming Rules
The rules in this section make use of the following special concepts related to XML elements and attributes:
.. Top-level element: An element that encloses a whole UBL business message.
Note that UBL business messages might be carried by messaging transport
protocols that themselves have higher-level XML structure. Thus, a UBL top-
level element is not necessarily the root element of the XML document that
carries it.
.. Lower-level element: An element that appears inside a UBL business
message. Lower-level elements consist of intermediate and leaf level.
o Intermediate element: An element not at the top level that is of a
complex type, only containing other elements and attributes.
o Leaf element: An element containing only character data (though it
may also have attributes). Note that, because of the XSD
mechanisms involved, a leaf element that has attributes must be
declared as having a complex type, but a leaf element with no
attributes may be declared with either a simple type or a complex
type.
.. Common attribute: An attribute that has identical meaning on the multiple
elements on which it appears. A common attribute might or might not
correspond to an XSD global attribute."

I would hesitate to say that two attributes with the same name always had the same
semantic meaning.

With a particular reusable core component type, unspecialized datatype or specialized datatype
then all attributes for that particular type will always be the same with the same names, the same 
xsd:datatypes and the same semantic meanings. A core component type called an
IdentifierType will always have the same set of attributes (it is reused by import) but an unspecialized type with
the same name (IdentifierType) may have another (restricted *) set of attributes. Although it is likely
that a specialized datatype with a particular attribute will have the same semantic meaning
as an unspecialized datatype with an attribute having the same name when they both are
derived from the same core compontent type, I'm not sure it is always the case (I'm not
sure if it is a CCTS rule but I don't think the NDR seems to be that specific about it).

(*  In the future, I think with the next version of CCTS (v3.0) I hear it might be that a specialized
datatype will be able to extend as well as restrict an unspeciailized datatype. This could perhaps impact
on UBL 2.0)

All the best

Steve