[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Two comments on Customization Guide Draft custguide092.pdf
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]