Re: UBL-TTSC: Action requested on use case discussion

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

On Tue, 9 Dec 2003, Anne Hendry wrote:
>>
>>Use case for Atomic compliance (use of UBL schema/ABIEs):
>>   User is free to use all ABIEs in UBL 1.0, but in use/reuse,
>>   schema fragements must remain intact - no modification of
>>   namespace, local names, etc. within adopted ABIE fragements.
>>   Eg. Warehouse Inventory Delivery document which is not a UBL
>>   document includes UBL Reusable:AddressType schema fragment,
>>   in full, as is, from UBL 1.0.

I couldn't do the summary better;  this is good.

The "Reusable" carries the meaning of XML prefix, and expands
to the namespace value of that defined for UBL's Reusable schema.
So there's no more than that in using the word "Reusable" as a
prefix.  In so far as NDR and LC are concerned, I think the
word "Reusable" has been consistently used to refer to the
Reusable schema.  But I can understand your concern about potential
cross-fire in meanings when one customizes and start "reusing"
or "using" types and elements.  However, I suppose the context
and case-spelling surrounding their uses would make it sufficiently
clear.



>>Looking at (5) again, it has several components.  Perhaps we should
>>split (5) into 2 or 3, and have this be one of the subsets?
>>Or just create new upper level ones from the contents of (5)?
>>It depends on how many buckets we might want.

I thought the list you condensed out of the discussion was good
because it gives a very useful summary of various thoughts on
how people see, or might see, customization take place.  We can
leave (5) as-is, and start by applying the Atomic Model of
customization and compliance to see if that works out for the
use case. 

For instance, applying it to (5)'s RosettaNet's needs, they
might have implemented a number of schemas on their own with
local definitions.  However, UBL's NDR has suggested using global
and has resulted in global definitions being applied across 
the UBL schemas.  Now, suppose RN looks at AddressType and wants to
"use" it with some modification:

   - adding 1 field called RN:SubZipCode of type xsd:int
   - not using Reusable:AddressType's "ID", and "AdditionalStreetName"
     fields.

These example modifications would serve to illustrate how we can
make a step forward in terms of customization.

There're immediately two clear ways of "using" it:
------------------------------------------------------------------
(A) Start from UBL Reusable:AddressType, and EXTEND.

    By the Atomic Model of Customization and Compliance (AMCC),
    they would not touch any field within AddressType.
    To use AddressType, they would define a RN:MyAddressType
    envelope around UBL's Reusable:AddressType, looking something
    like (in the instance space):

    <RN:MyAddressType>
       <Reusable:AddressType> 
         .. atomic content structure .. 
       </Reusable:AddressType>
       <RN:SubZipCode>
         <RN:MainPart> ... </RN:MainPart>
         <RN:SubPart> ... </RN:SubPart>
       </RN:SubZipCode>
    </RN:MyAddressType>

    Note that the RN:SubZipCode structure could be defined within
    RN schema to be locally defined elements and it would still
    interoperate and not affect UBL's Reusable:AddressType 
    definition.

    On address their (example) need to not use AddressType's
    ID & AdditionalStreetName, RN would document in the usage
    of their new "RN:MyAddressType" to specify that sender's
    MUST always not define the contents of (XPath) 
    AddressType/ID and AddressType/AdditionalStreetName.
    This is permitted under current definition of UBL's 
    AddressType as the minOccurs are "0".  


(B) Start from RN's intended MyAddressType2 (to differentiate from
    (A)'s definition), and pick from the buffet menu the components
    within Reusable:AddressType, which are atomic BBIEs or ABIEs.

    A sample instance would then be:
    <RN:MyAddressType2>
       <Reusable:Postbox> .. atomic .. </Reusable:Postbox>
       <Reusable:Floor> .. atomic .. </Reusable:Floor>
       <Reusable:Room> .. atomic .. </Reusable:Room>
       <Reusable:StreetName> .. atomic .. </Reusable:StreetName>
       <!-- Skipped inclusion of <Reusable:AdditionalStreetName> -->
       <Reusable:BuildingName> .. atomic .. </Reusable:BuildingName>
       <!-- Other selected UBL BBIE/ABIEs -->
       <RN:SubZipCode>
         <RN:MainPart> ... </RN:MainPart>
         <RN:SubPart> ... </RN:SubPart>
       </RN:SubZipCode>
    </RN:MyAddressType2>

    This constructive build-up process automatically satisfies the
    initial requirements spelled out above on addition of new field
    to and removal of unwanted fields from Reusable:AddressType.

------------------------------------------------------------------

There's no right or wrong way to (A) & (B);  there may be perfectly
valid reasons for even the same person/organisation to use (A) 
sometimes (e.g. simplicity, more than 80% fields of AddressType
is needed, no resources to purchase consultancy to redo everything,
etc),  and to use (B) (e.g. my organisation XML Guide requires
such, only a few fields within AddressType look usable for my
purpose, the new type has a lot more extensions and will merge
in better if the individual sub-fields of AddressType are exposed,
etc).

In the real world, one size doesn't fit all.  I think people will 
just pick the way that fits their purpose most.  In both cases, 
the AMCC caters to those needs without restricting all of them to 
do and provides alternative means, allows interoperability
at structure and semantics level with all UBL users, and yet
has room for alternative manner of implementations.



>>What is your description of the target user group for this scenario?

People who want to customize, extend, use UBL's work, and
wants to say with verificable means whether they are 
"compliant" or not with UBL.



>>I also think we should remove the I18N case from (6) and make it
>>its own.  If we did that, then do you agree that the remainder
>>of (6) would be ok as 'discouraged'?

The I18N example is really a separate issue, actually not-a-issue
in the sense that it goes to the underlying XML encoding and doesn't
"surface" to the level that UBL TC is looking at.  The larger
issue is namespace definition and use, and that includes the
resulting effects of I18N examples on namespace changes due to
encoding effects.

Maybe I haven't understood your original intent of (6).  Presumably
you've wanted to document the thought about localising due to
language/ character-set requirements?  If so, my apologies as
what I said would be off-tangent to that.


Where I was steer off-course from your I18N description in this 
sense would be the sentence 
   "make a proprietary version of ubl taht only they can use - 
    keep ubl as is and change the namespace to proprietary.
    non-compliant compliant schema".

By customization, one always "makes it a proprietary version".
So if "proprietary" has some negative connotations to that, we
would better stick to "customization".

The AMCC suggests "keep(ing) ubl as is".  Maybe the commonality
between AMCC and (6) stops right there.


If it makes sense to you and the rest of the people, we could
put in a (7) of sort.  But I'm more interested in testing the
applicability of AMCC until I see an unresolvable deadlock
that AMCC fails to provide.  Then the course of action would
be to see how to modify till it works (if possible), re-visit
how AMCC applies to the test cases, or conclude if something
else is better.




>>Regarding testability/computability of the compliance definitions,
>>yes, this is one of the things that took us into this discussion in
>>the first place.  I see that tools has requirements for the complianc
>> implemenation.  From your email, this would be:
>>
>>    * Compliance must be reasonably computable/testable.
>>    * Given several compliance algorithms, the most computable would be
>>      preferrable.

Small correction:  It's "Given several compliance definitions",
not "compliance algorithms".  I hope I don't sound like picking
bones in an egg.  There's a difference here.  We are searching
for a "compliance definition" first, then algorithms and programs
can be developed to test that compliance definition.

The primary goal is to come up with such a compliance definition
in such a ways that:
    (1) computable/ testable algorithms *can* reasonably be developed,
    (2) the algorithms/programs can scale in terms of types of schemas
        and numbers of schemas.




>>I'll begin a list of such requirements as we go through this discussion.
>>If anyone has any others off the top of their heads let me know
>>(as long as it doesn't pull focus off the work of clarifying these
>>use cases at the moment, though.

I'll ask members of the group to go with Anne's suggestion
so her task is easier and she'd find more fun and spend more
time in this group  :)




>>FYI, in the lcsc discussion this morning Tim mentioned that
>>in his view there are multiple facets to compliance:
>>semantic, syntactical, and structural.  If this is
>>helpful to organizing our use cases let's apply these.

Yes, I'd agree with Tim's point.  I'd add that ultimately,
someone, perhaps this SC, needs to translate those 3 compliance
needs into more concrete compliance definitions that adhere
to (1) and (2) above.  I think the AMCC addresses semantic
and syntactical compliance (defining  "compliance definition"
as "compliance with AMCC itself").  

As for structural, different people would have different take
on this.  On first look, I'd think it means how the files
are grouped, what goes inside, etc.  But I'm not sure how
others look or if there's another aspect to that word.


>>
>>Thanks,
>>
>>-Anne
>>
>>
>>Chin Chee Kai wrote:
>>
>>> Great summary, Anne.
>>>
>>> As a start, I like to play with the idea of treating each UBL-defined
>>> ABIE as an atomic structure.  We can modify the concept along as we
>>> go.   We must keep in mind
>>> that while we wrestle with the axes of
>>>     - interoperability
>>>     - customizability/ extendability
>>>     - compliance
>>>
>>> we must also keep in mind the need to arrive at addressing
>>> those issues with simplicity of algorithms to check them.
>>>
>>> Given several means of defining compliance, for example,
>>> a more preferred one would be a compliance definition that
>>> is computable.  Ie., we can *develop* programs to check
>>> compliance, AND the programs would run reasonably well
>>> when scaled to larger schemas.  A compliance definition that
>>> is too abstract would not even result in the possibility or
>>> ease for programs and algorithms being developed.
>>>
>>>
>>> Now a bit more on what I think about the atomic model of
>>> compliance.
>>>
>>> In other words, a user who wishes to use any ABIEs delivered by UBL
>>> 1.0, including those ABIEs in Reusable, and the 8
>>> main documents (which are themselves ABIEs), MUST keep
>>> the ABIE schema or schema fragment in tact.  This means also namespace
>>> values and local names and every thing.  No modification is admissible
>>> within the adopted ABIE
>>> framents.
>>>
>>> With this definition, "using UBL schema/ABIE" would mean using any of
>>> UBL-defined ABIE.  Where they are used in user-extended
>>> schemas (that contain these UBL ABIEs), the compliance check
>>> is simply that that UBL ABIE that is adopted matches in complete
>>> structure with what UBL has defined.
>>>
>>> E.g. if a user uses Reusable:AddressType (Reusable prefix
>>> defined with namespace for Reusable schema) in his/her
>>> schema for WareHouse Inventory Delivery Document,
>>> then while that document is almost certainly not UBLish,
>>> the address field that is defined with Reusable:AddressType
>>> would have to be fully equatable with UBL's AddressType
>>> definition.
>>>
>>> Such comparisons are easy and unambiguous enough that
>>> even humans could visually detect any "non-compliance".
>>>
>>>
>>>
>>> Up to here, I hope I've given an inkling of what path
>>> down the road I'm heading.  Let me give a bit more thoughts
>>> to it and see how this exposition could be fanned out
>>> further, or modified in concept, or whether some aspects
>>> are fundamentally incorrect with this conceptual approach.
>>>
>>>
>>> Therefore, Anne, in your excellent summary, I'd just like
>>> to point out that Point (6) is not necessarily "not to be
>>> encouraged".  It is quite complementary to (5), and appears
>>> from the sound of it to be very compatible with an atomic
>>> model of interoperability and compliance definition.
>>>
>>>
>>>
>>>
>>> Best Regards,
>>> Chin Chee-Kai
>>> SoftML
>>> Tel: +65-6820-2979
>>> Fax: +65-6743-7875
>>> Email: cheekai@SoftML.Net
>>> http://SoftML.Net/
>>>
>>>
>>> On Tue, 9 Dec 2003, Anne Hendry wrote:
>>>
>>>>> Hi,
>>>>>
>>>>> If you've recieved this email I believe you were one of the people who
>>>>> participated in the TTSC 'user case' discussion last week.  Below are
>>>>> my notes from that discussion for your review in order to clarify what
>>>>> was said so that we can use this as the basis for a larger TC
>>>>> discussion.
>>>>>
>>>>> ...
>>>>>
>>
>>
>>