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

From: Stephen Green 
[mailto:] 
Sent: Monday, April 25, 
2005 8:52 AM
To: 
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.

 

 

Mark