[ubl-lcsc] Re: [ubl-ndrsc] MINUTES: Joint NDR/LCCSC 4 Feb 2003

[Tim McGrath <tmcgrath@portcomm.com.au>]

i've trimmed this thread to focus on the issues still under debate...

Eduardo Gutentag wrote:

> So let's see if we're in sync: there are three instances of Order, 
> created
> based on the UBL Order schema, and the three of them validate against 
> that
> Schema? So if you created an Order from Sally's data, what happened to 
> the
> data she had that required customization?

i implemented her 'extensions' by adapting the current components.  for 
example,
            <cat:ManufacturersItemIdentification>
                <cat:ID schemeAgencyID="81205">256T2800122</cat:ID>
                <!-- using the schemaAgencyID for the Manufacturer's ID -->
            </cat:ManufacturersItemIdentification>
- instead of having a new element for Manifacturer's ID, i utilized the 
attribute within the identifer to specify how set the ID.  This isn't 
necessarily a good thing - but it shows how it could be done.

another kludged example is...

            <cat:CatalogueItemIdentification>
                <!-- using catalog to define industry identification 
codes -->
                <cat:ID>N000001</cat:ID>
            </cat:CatalogueItemIdentification>
            <cat:ReferencedCatalogue>
                <cat:CatalogueID>AviationAuthority</cat:CatalogueID>
            </cat:ReferencedCatalogue>

- where instead of needed a new aggregate for aviation identifiers, i 
used the view that this was a type of cataloging - produced by the 
avaiation industry and the item we were referring to was given a code in 
that catalog.

>
>>
>> ps personally, i am not sure any annotation needs to be normative - 
>> the documentation does not immediately impact interoperability.
>
>
> I beg to disagree. If the documentation says that a developer should 
> treat
> a given element or attribute in a certain way, but the documentation 
> is not
> normative, then different developers will treat that element or attribute
> differently, and you've just killed interoperability. Even taking
> your point above, that schemas are equivalent to the spreadsheets and the
> UML diagrams, then we should treat the documentation comments in the 
> spreadsheet
> that need to be normative exactly the same in the schema, shouldn't we?

i deliberatly used the word 'immediately' and i do sympathize with your 
view.  

i noticed this issue was followed-up with Marion's note about Jon's 
proposal to LC....

>Jon also proposed that the LCSC be responsible to make sure that:
>1. All "annotation" in the spreadsheet be normative *only* (which means
>that LCSC would remove all from the description column that is not
>normative.
>
>  
>
our current annotation/documentation defines attributes as ...
            <xs:attribute name="dictionaryEntryName" type="xs:token" 
use="required"/>
            <xs:attribute name="qualifierObjectClassTerm" 
type="xs:token" use="optional"/>
            <xs:attribute name="objectClassTerm" type="xs:token" 
use="optional"/>
            <xs:attribute name="qualifierPropertyTerm" type="xs:token" 
use="optional"/>
            <xs:attribute name="propertyTerm" type="xs:token" 
use="required"/>
            <xs:attribute name="representationTerm" type="xs:token" 
use="required"/>
            <xs:attribute name="businessTerm" type="xs:token" 
use="optional"/>
            <xs:attribute name="definition" type="xs:string" 
use="required"/>

i take from Jon's proposal that we should not use any narrative text 
definitions and business terms from our XSD schema documentation (the 
last two attributes). this is because we cannot honestly say 'to be UBL 
compliant, you must understand what this definition means'.  I don't see 
how they could be normative.  The remaining attributes are necessary for 
CCTS compliance (which i think was Mark's point).

This would seem to satisfy everyone's concerns - we have a normative XSD 
and a non-normative models (spreadsheet and uml) that contain further 
meta-data that is non-normative.  however, we must ensure that the 
normative components needed by the XSDs remain aligned between these 
models.

-- 

regards
tim mcgrath
fremantle  western australia 6160
phone: +618 93352228  fax: +618 93352142