RE: [ubl] further design considerations for 2.0 (prototype '-sdg-2' atta

From: Stephen Green [mailto:stephen_green@seventhproject.co.uk]
Sent: Monday, April 25, 2005 8:52 AM
To: ubl@lists.oasis-open.org
Subject: [ubl] further design considerations for 2.0 (prototype '-sdg-2' attached)

Greetings

> The first step, already demonstrated, was to show that

> there are problems introduced with the local declarations

> of IDs and Codes in 1.0, hence the decision to remove

> this design aspect by moving to a 2.0 major version.

> The main problem introduced with these local elements

> was in the fact that the instances for 1.0 would, if a

> minor version used polymorphism with imports of these

> schemas, require a change to the local elements from

> default namespace without prefixes (e.g. in:Invoice/ID)

> to element names with prefixes (e.g. in:Invoice/in:ID) for

> tehm to be valid against the new schemas. This is

> considered to be an undesirable compromise of backwards

> compatibility in one sense of our understanding of it.

Although we have not yet agreed to substitution groups, eliminating the global/local differences make good sense.

> I've tried to test this a bit further by making the change

> to the IDs and Codes and then using the substitutionGroup

> mechanism in subsequent prototypic minor versions

> and I've found that this change may not quite be enough.

> To allow minor version schemas to correctly validate the

> major version instances with only minimal changes (e.g. just

> schema location and the like) to the instances it appears

> (as the attached prototype demonstrates) that we have to

> make two further changes to the document schemas:

> Firstly there are in UBL 1.0 some BBIEs declared in the

> document schemas rather than in the common (CBC)

> schema and these would have to be moved to CBC;

> Secondly there are in UBL 1.0 some ABIEs declared in

> the document schema and these too would have to be

> moved to the common schema (CAC).

I have long felt that this was a mistake on the part of the LC committee. We created internal schema for this purpose. Rather than move these definitions/declarations to the CBC and CAC schema indiscriminantly, lets look at each on a case by case basis and determine if they are more appropriate in internal schema.

> 1. Moving two Codes, ReasonCode and IdentificationCode

> to the common module (CBC) there may need

> to be a renaming of the elements since the names are

> far less specific in 1.0 than the datatypes which

> are tied to quite specific codelists (namely

> AllowanceChargeReasonCode and CountryIdentificationCode).

> There is also a general principle here to which we'd

> need to adhere more in modeling with this new design:

> that the more specific the datatype (e.g. a more

> specific codelist), the less generic should be the element

> name.

Do we need to consider more SDT's?

> 2. We need to clarify whether an ID element should

> have a complexType named IDType or IdentifierType

If we are going to be consistent, then it would have to be IDType - unless we remove ID as an approved abbreviation

> There may be other improvements to such naming

> rules we'd like to make too (some type names seem

> too arbitrary generally).

Is this a naming issue, or a library issue?

> 3. Does an xxxxCode element have to have a

> complexType name xxxxCodeType or is just CodeType sufficient?

> Is this covered by NDR?

I believe it is covered, and it must be xxxxCodeType.

> 5. The NDR and other schema module diagrams will need

> reworking since the patterns of imports will change.

> I hope the attached prototype will help with this.

I will take this for action once we finalise our modularity model to reflect adoption of the CEFACT CCT, UDT and QDT schema's.

> 7. If the reasoning about the need to define all of the

> document BIEs in CAC and CBC schema modules are accepted

> this may need to be explicit in the NDR

agree

> 9. There will likely be frequent occasions when a type to

> be extended was not explicitly declared in the previous version

> (if only the types we changed in that version were explicitly

> included, as required for modular rather than blanket revisions).

> This does then require (as in the 2.2 schema of the attached

> prototype - Delivery example) the import of earlier version

> schemas such as the previous major version and with it the

> older namespaces and suitable prefixes. This then means that

> we are likely to need rules to define separate suitably named

> prefixes for each version and these should ideally include

> some indication of the version number (perhaps even for the

> major version). For example, I have used cac2-0, cac2-1, etc.

Agree with the need to address this, but not necessarily your approach.

> 10. I do not forsee problems incorporating the ATG2 CCTS

> schemas into the prototype (though I haven't done so here)

> - see previous mail with such a design prototyped. But the

> complexities of the polymorphic versioning may be quite a

> challenge, it seems, to keep it in step with the ATG2 design -

> mainly considering possible namespace aspects (as seen

> in point 9 above). This concerns whether instances with the

> necessary multiple namespaces/prefixes for the UBL design

> instances could be catered for in an ATG2-type set of schemas.

> Whether instances valid to the ATG2 schemas could have

> the necessary complexity of namespaces to validate against

> corresponding UBL schemas is what seems an increasingly

> challenging prospect as the real details are considered.

We need to keep in mind that ATG will most likely remain local element based. We will need to carefully weigh our polymorphic processing solution to ensure that whatever we come up with will support interoperability with ATG instances.

ubl message