Re: [ubl] Use cases (UBL compliance)

[Tim McGrath <tmcgrath@portcomm.com.au>]

One of this perspectives to bear in mind when starting this discussion 
is the overall UBL architecture.  This is alluded to in the use cases 
below, but we should be more specific in our  descriptions and more 
consistent in our terminology (we use words like Party for 'Entity'. 
 Entity is a BIE.)
I include my thoughts in the text below
PS
sorry Jon I am including your email personally  as i dont know if you 
are on the TTSC list.

jon.bosak@sun.com wrote:

>Hello UBL TC,
>
>
>Anyone who wishes to participate in the current analytical
>exercise should contact Anne Hendry regarding TTSC meetings.  But
>please bear in mind that the TTSC is not chartered to make any
>decisions in this area.  Important as it is, the document below
>should be considered a preliminary input to a much larger
>discussion.
>
>Jon
>  
>
>
>I. UBL User scenarios
>
>We began with a few simple questions based on the idea that if we
>are to develop and/or document the use of tools for developers of
>UBL 1.0, we must be able to say with certainy that the output of
>the tool is UBL compliant.  But there is no comprehensive
>definition of UBL compliance.  For tools, a lack of definition
>here is a showstopper.
>  
>
i am not sure why this is a show stopper in terms of identifying tools 
and/or designing them.  certainly it stops anyone claiming a 
UBL-compliant tool, but are we there yet?

>It was decided to begin an analysis of some known use case
>scenarios with an eye towards the question of compliance - what
>types of compliance are indicated by typical use cases - then sort
>into common use case models.  This must start with what people
>want to do in business.  From there we discussed the need to
>identify compliance 'levels' based on these use cases.
>  
>
i am attaching three slides i use in my UBL presentations.  these 
identify 3 use cases (similar to those below) and then relate them back 
to the UBL architecture.  That is, we need three levels of compliance... 
syntax level, schema level and semantic level.  these can be combined or 
separate.

The use cases you describe seem to overlap with our architecture and i 
personally find this confusing.  

use case number 1.  - (no customization).  this needs clearer 
definition.  it assumes we know what a standard document is.  what does 
this mean in terms of UBL code sets?  only the standard codes are used? 
 if any party opts for additional code sets (and they almost definitely 
will) what does this mean for 'standard' documents?  Also, be careful 
about analogies with EDI - the scenario you decribe is exactly the same 
justification as was claimed by EDI standard bodies.
In general terms, this use case is claiming syntax, schema and semantic 
level interoperability.

use case number 2. (UBL compliant schemas) - is schema interoperability 
(see slides).  this is the thing that the CM subcommittee are defining.

use case number 3. (UBL label compliance) -  combines semantic and 
syntax interoperability.  Schematic interoperability (re-assembling UBL 
ABIEs) is not a constraint as they will want to invent their own.  But 
how does this scenario decription allow for semantic interoperability? 
 By definition two separate 'trade and transport' domains cannot both 
grow UBL into the same context?  The only way we can hope for that is to 
have a universal conceptual model - where each BIE is defined once and 
once only. Even if a diverse domain (maybe the Vision Council) attempted 
to customize their own UBL, they could not do so without being aware of 
all other UBL customizations or else they could duplicate defintions.  
Ultimately someone (and it could be either the CEFACT TBG17 group or the 
UBL TC) must own the semantic model for UBL.

use case number 4. (subset UBL) - this is syntax interoperability. i am 
not sure i understand how you can say 'no new BIEs'?  do you mean they 
develop their own BIEs in their own namespaces and dont tinker with UBL 
ones?  i also suggest this is not rare at all.  from the description i 
think this one means 'complies to UBL NDR'.  Isn't this what RossettaNet 
and the US government projects are planning?

use case number 5. (interoperability with UBL) - this is semantic, 
schematic and syntax interoperability for only the UBL BIEs used.  In 
that sense isn't it a variant of use case 1.  - instead of using whole 
documents, they use only parts?

use case number 6. - (localization), is a furphy.  the localization 
committees are not interested in translating XML tags (or any other part 
of the XML componentry).  These are machine-processable labels, language 
is irrelevant.  What they do want to translate is the documentation. 
 Localization is in fact and example of use case 3.

>==================================================================
>
>II. A mechanism for instance-based compliance validation
>
>What is described below is a work-in-progress.  It is a mechanism
>for validating UBL at the instance level that appears to fulfill
>the requirements posed by the above scenarios for the use of UBL
>1.0.
>
>  
>
this appears to overlap with the Context Methodology in its schematic 
compliance.  I am not sure it considers semantics or syntax at all.

for example, if the RN fragment below was...

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

    </RN:MyAddressType>


 - where would an implementor put the number within the street of the 
address.  UBL has BuildingNumber and BuildingName in its AddressType but 
Rn has HouseNumber and HouseName???.  This may seem trite but this is 
actually the real problem with business vocabularies - aligning the 
semantics.  The schematics are mechanics and the syntax  is just agreed 
sets of NDRs.

>
>==================================================================
>
>III. Miscellaneous
>
>    - Need distinction between evolution, extension, addition, ...
>      what kinds of things can these concepts apply to?  what
>      things can you extend?  library, ndr, schema ?
>  
>
i agree this is the big issue Jon mentioned in his email to the TC. 
 obviously it is not a TTSC issue.

>   Initial questions raised:
>
>      "What does it mean to be UBL compliant?"
>
>      "Does UBL compliance equate to CCTS compliance?"
>  
>
of course not, UBL is compliant to CCTS but you can implement and comply 
to part of UBL without using CCTS (e.g. use the schematics)

>      "What is the difference between contextualization and
>      customization?"
>  
>
UBL has decided that context is used to define the schematic difference 
from one schema to another.  we are using customization to cover all 
forms of changes to UBL (sematics and syntax) - i prefer this to 
'context philosophy'.

Developing a Customization Methodology is a deliverable of the LCSC charter.

>      "Where is the use case analysis of context and
>      customization?"
>  
>
CM has use cases that may answer this.

>      "How much can a user change in the UBL schemas and still be
>      'UBL compliant'?"
>
>      "How do we ensure compatibility / interoperability of UBL
>      schemas?"
>
>      "How to implement customization and contextualization and
>      still keep compliance between releases?"
>  
>
all of these are good questions.  we must also bear in mind that 
implementors will choose the level of compliance and its inherant 
interoperability potential based on their own requirements.  we cannot 
and should not enforce compliance with tools - but we should verify it.

>      "To what degree should a tool allow relaxing of NDR rules?"
>
>  
>
i think this is a case of what i meant by 'we cannot and should not 
enforce compliance with tools - but we should verify it.'

>To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/ubl/members/leave_workgroup.php.
>
>  
>

-- 
regards
tim mcgrath
phone: +618 93352228  
postal: po box 1289   fremantle    western australia 6160