Two comments on Customization Guide Draft custguide092.pdf

[Chin Chee-Kai <cheekai@softml.net>]

With reference to Customization Guideline draft at:
http://www.oasis-open.org/committees/download.php/29263/custguide092.pdf

There's a lot of good work done.  Two points I'd like to check my 
understanding to see if I've misread the intention:

(1) Lines 199-200:
     A UBL conformant schema is a schema that will validate only UBL 
conformant instances

While I think I understand the intended idea, the way it is expressed 
couldn't be generalized.

Eg. UBL-conformant schema A uses AddressType with all cardinalities set 
to 0 except AddressLine element.
UBL-conformant schema B uses AddressType ignoring AddressLine by setting 
its cardinality to 0.

Both are UBL-conformant, but schema A cannot validate UBL-conformant 
instances of B and vice versa.

Perhaps a clearer way to nail the open ends would be to say:

     A schema is UBL conformant if and only  if all the instances it 
validates are UBL conformant.

(where the meaning of a UBL conformant instance has been defined earlier)
This ensures that the conformance of a schema is measured by the set of 
all instances it validates, rather than measuring it against other 
instances.

Using  the same examples, the set of all instances validatable by schema 
A are those that use only AddressLine element.  So by this definition, 
schema A is UBL conformant.  Likewise, the set of all instances that can 
be validated by schema B are those that use possibly all elements but 
never AddressLine element.  So again, schema B is UBL conformant.

Is this understanding correct?


(2) Lines 540-545

    Example
    A UBL Address is always the same structure. If any entity is added
    to, or required entity
    is removed from, the UBL Address, it can no longer be identified as
    the UBL Address. It
    is recommended that it be given a qualified name to reflect that it
    is not a standard UBL
    Address. For example, Customized_Address.
    This change of identity bubbles or ripples upward through any parent
    of Customized_
    Address.
    This rule guarantees that UBL-consuming code is never "surprised" by
    an unexpected
    difference hiding inside an incoming data structure wrongly
    identified as standard UBL. This
    difference must at a minimum be indicated by a change in XML namespace.


Using the same schema A & B examples above, both schemas have removed 
some element/s from AddressType by setting cardinality to 0.  However, 
at the instances level, it is not possible for the UBL-consuming code to 
distinguish whether that instance has had elements removed or not, and 
consequently decide become "surprised" (eg fault or crash) due to that.  
This is because an instance of schema A validates not just schema A but 
also UBL standard schemas.  Likewise, an instance of schema B, which 
looks like the inverse of schema A with respect to standard AddressType, 
also validates properly with UBL standard schemas.

The intended purpose of guaranteeing that UBL-consuming code is never 
"surprised" by such removal of elements in schema designs of A & B is 
therefore nullified and not achievable.  Consequently, the guideline 
suggesting customizing user to switch namespace or change identity might 
not be  useful in achieving maximal re-use of UBL types and at the same 
time achieving intended customization effects.

If the intention is more targeted at the phase of design of schemas 
rather than validation, then perhaps it could be made clearer.  In any 
case, the AddressType example as stated wouldn't quite  gel with 
guidelines suggested in other parts of the text.

For TC's consideration please.


Chin Chee-Kai