OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [ubl-dev] Two comments on Customization Guide Draft custguide092.pdf

Hello Chee-Kai,

Good to hear from you!

These are great comments, but it's not time yet to get feedback
from people who aren't on the TC.  In about a week, OASIS will be
putting the draft out for a 60-day public review, and at that
point, we'll be actively soliciting feedback through the UBL TC
comments form at


So please hold these comments for the moment and then submit them
through the form above as soon as you see the public review

It probably seems strange that we have to officially ignore good
nonmember input just because it comes in the wrong way.  It's all
about IPR policy.  We can't officially take cognizance of any
nonmember input that doesn't come in through the comment form.
This is the reverse of the usual problem, which is people using
the comment form to ask questions that should go to ubl-dev.

Note that there's nothing to prevent other subscribers to ubl-dev
from discussing the points you raise on ubl-dev.  We just can't
use any of it.


Chin Chee-Kai wrote:
> 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]