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