Re: [ubl] Use cases (UBL compliance)

[Anne Hendry <anne.hendry@sun.com>]

Hi,

I'd like to acknowledge the TTSC members who contributed to the discussion
that produced the use cases and other thoughts put forward in this email:
Chin Chee-Kai, Tony Coates, Michael Dill, Stephen Green, Chris Nelson,
Sue Probert, Lisa Seaburg, and Ray Seddigh.

As Jon mentioned, this is a topic of concern to most of the UBL SCs.
We hope the thoughts presented here will server as a catalyst for
cross-SC discussion and clarification of these areas, since each
SC holds a piece of the answer to this overarching question.

Thanks,
Anne
 

jon.bosak@sun.com wrote:

>Hello UBL TC,
>
>As a prerequisite to building tools to support UBL, the UBL Tools
>and Techniques SC has recently been exploring the question of what
>it means to be "UBL compliant."  The document below, from TTSC
>co-chair Anne Hendry, summarizes their analysis so far.
>
>I am bringing this to your attention for two reasons: first, to
>make people who might be interested in this subject aware of the
>discussion, and second, to raise it as a fairly large potential
>coordination issue that cuts across several other SCs and begins
>to address the directions that UBL may take after 1.0.  This has
>therefore been logged as an issue (2003-1212-11) for consideration
>in an upcoming coordination meeting.
>
>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
>
>##################################################################
>
>[Anne Hendry:]
>
>There are 3 sections to the document:
>
>I. Use cases/scenarios.
>
>II. A mechanism for instance-based compliance validation,
>    a kind of strawman design for validation that everyone in
>    the meeting thought had a lot of merit.
>
>III. Some issues and questions.
>
>The use cases described in section I are broken into 4 or so
>subsections.  You can ignore the 'Additional Thoughts' part - that
>makes it a lot shorter.  I don't want to separate those, though,
>because they really are part and parcel of the scenario
>description, just a less formal part.
>
>The last 2 sections (II and III) are there because they are artifacts
>of the Section I discussion.
>
>==================================================================
>
>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.
>
>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.
>
>Categories of UBL implementors (use case scenarios):
>
>
>1) Most basic UBL use case; no customization; use UBL as is
>   Target audience: developer and business users; non-tinkerers
>   Level of compliance: highest
>
>   Scenario:
>
>   Entity A sends entity B a UBL standard document with a UBL
>   namespace.  Entity B responds with a UBL standard document with
>   a UBL namespace.  The meaning of what was sent would be
>   immediately known to both entities with zero initial processing
>   required.  This would be independent of the application for
>   interpretation.
>
>   Use Case:
>
>   Large organization with not much money (eg. government,
>   university, etc) wants an inexpensive way to automate exchange
>   between a multitude of small suppliers.  80% of their suppliers
>   are small businesses.  They use UBL as the common payload to
>   automate those suppliers sending them invoices from a website.
>   All they need to do is process UBL to cover 80% of their needs.
>   Much of this is being handled currently with procurement cards.
>   UBL could be used instead.
>
>   Additional thoughts:
>
>    - All that would be needed here is an understanding of
>      businees rules.  Completely NDR compliant. Using UBL as a
>      legal standard in and of itself.
>
>    - Not sure how common a case this will be, since it's unlikely
>      anyone will want to use everything in a document and want no
>      customization.  This is what we're trying to get away from
>      in EDIFACT.  XML allows you to hone the schema.
>
>    - This may be an interesting case for that same reason as
>      above - simplicity will allow anyone to send an electronic
>      invoice that will be understandable to anyone else using
>      vanilla UBL - and it's cheap.  This would be a case where
>      everyone knows the schema.  The receiver may not even be
>      able to process it electronically, but could process it
>      manually.
>
>    - Because there is no subsetting/customization, a larger
>      entity receiving documents from multiple suppliers would
>      have to understand all of each UBL document.  This would put
>      more burden on the larger entity but they are the one most
>      likely to have the ability to fund the implementation.  In a
>      way it's a reversal to EDI.  There the pressure was on the
>      seller/supplier.  Now, if it's cheap to the supplier, and
>      the buyer, who usually has the money, can put together one
>      system (only one needed!) to process UBL.  This still makes
>      it less expensive all around.  This also makes it more
>      important for there to be only one way for doing UBL.
>
>2) Generating 'normative' UBL compliant schemas (almost out-of-the-box)
>   Target audience: developer
>   Level of compliance: full  
>
>   Scenario:
>
>   When an Entity creates an instance from a schema that has been
>   customized in some way from a UBL normative compliant schema.
>   The instance should then be able to be validated against the
>   original UBL normative compliant schema.  The namespace remains
>   UBL, but the implementation is tighter - a greater restriction
>   than is normal for UBL.  The restrictions may be due to
>   internal processing requirements, but want to be sure that
>   whoever receives the document would be able to process it as a
>   UBL doc.
>
>   Use Cases:
>
>    - Users that want to use UBL but want to customize UBL (to
>      extend or restricted) perhaps between their close trading
>      partners, and still want their instances to be valid to
>      anyone else using UBL - to guartantee that other users of
>      UBL can use their documents.
>
>    - Software developer that needs to restrict the UBL schema but
>      still wants the application they're writing to be able to
>      send a UBL document with the guarantee that it complies (is
>      valid) according to the normative UBL schemas.
>
>    - A company with an internal system that can only handle a
>      restricted type of value/amount (say the system can only
>      cope with 9 digit amounts) and in trading with others who
>      are using UBL have agreed with them to only send amounts <=
>      9 digits - or if one comes in with more than that it may
>      have to be dealt with manually.  This is defined in the
>      schema.  But it has to be done in such a way that the system
>      can still deal with normal UBL schemas, and know that when a
>      schema is generated it will still validate.  The company
>      might actually choose to send out the restricted schema to
>      their main suppliers to pre-validate so they only get sent
>      what validates against this internal restricted schema.  Or
>      an application can be written with a 'click here to
>      validate' based on a particular trading partner.
>
>    - An Entity can only accept/handle a particular restricted
>      code list, but can't stop others from sending other types of
>      code lists.  Internally only want to work with the
>      restricted code list, but have to be able to take others
>      (even if they are just then dropped on the floor).  Some of
>      this is dealing with legacy.
>
>   Additional thoughts:
>
>    - It may not be possible to customize ubl in this way because
>      of the namespace issues, but this is the requirement.
>
>    - Tools need to flag non-compliant behaviour.  If someone
>      sends an invoice to another and the sender has a greateer
>      restriction reguired, how can the receiver, who doesn't know
>      about that restriction, still be able to validate that
>      scheama?
>
>    - Entity may want to adapt UBL (restrict) to their system
>      while still acknowledging the need to receive an invoice
>      from any other.
>
>    - There must be some algorithm to validate this restricted
>      schema.  This is vaguely like what derivation allows you to
>      do, as in the Beta Customization guidelines, but not
>      changing the namespace.  Even if the namespace was changed,
>      wouldn't be able to change it in the generated instances, so
>      would have to turn off validation.  Then schema wouuld just
>      be a definition.  Need more than what is currently in the
>      Customization guidelines to deal with this?
>
>    - Would apply to ubl docuemnts/schemas created in future; also
>      open horizontal schemas that are intended to be
>      many-to-many.
>
>3) UBL label compliance - evolution of UBL
>   Target audience - all industries/uses
>   Level of compliance - full (beyond NDR)
>
>   Scenario:
>
>   An Entity has generated a set of components and schema they
>   want to call 'UBL XYZ' and have it viewed as a normative UBL
>   document, even if it's not generated by the UBL TC.  Suggests a
>   UBL 'stamp of approval'; UBL being expanded beyond procurement.
>
>   Use Case:
>
>   An entity in another context (geopolitical, vertical industry,
>   government) wishes to have a special version of UBL for their
>   area - to create new components to add to the library and
>   generate new documents from those components.  Eg. passport
>   services - UBL doesn't now have a passport number.
>
>   Additional thoughts:
>
>    - The registration of documents to be called 'UBL' but not
>      generated by UBL TC is not addressed yet.  Would need to
>      comply with all OASIS requirements as well (eg. royalty
>      free).
>
>    - Such efforts would possibly generate not only the BIEs and
>      schemas for UBL, but CCs for harmonization.
>
>    - We are doing initial docs, but it will be up to consumers to
>      standardize new documents that are needed - then this will
>      be like a harmonization process.
>
>    - This aligns with the UBL goal of reducing fragmentation.
>
>4) Extend and/or restrict UBL (subset)
>   Target audience - vertical industry
>   Level of compliance - high
>
>   Scenario:
>
>   Those seeking greater convergence by adopting UBL NDRs or don't
>   have their own rules and think UBL NDRs are the best.  Have
>   bought into harmonization, so rules usage is stricter.
>   However, they still want their own namespace.  Will seek UBL
>   NDR compliance but are prepared to adapt certain rules if
>   needed.  Uses existing library, no new BIEs.
>
>   Use Cases:
>
>    - A large industry (vertical) wants to use UBL but require
>      their own namespace.  Are developing new ways to work with
>      UBL-related documents, are developing new rules, context
>      methods, etc.  Not extending.
>
>    - Large horizontal standards bodies who are seeking maximum
>      convergence with UBL but can't sacrifice their own
>      namespace.
>
>   Additional thoughts:
>
>    - Must have a more clear decision on what can be
>      extended/resricted (extend library, ndr rules, syntax,
>      methodology, structure, semantics?).
>
>    - Similar to above, if this is applied to a new domain would
>      require extension of ndr for new names and entities
>      (eg. dictionary of abbrevs) it would proabaly fall to the
>      new domain to create their documents, (not to lcsc?).  Would
>      need their own controlled vocabulary, since this implies new
>      components.
>
>    - Will be relatively rare, but still a possibility.
>
>    - What is complaince in this case?  The main issues are same.
>      Extension of current 7 docs is a good goal but not a
>      reality.  It works as long as you are extending only the
>      documents in UBL itself.  But not if you try to use NDR
>      rules for non-UBL document schemas.
>
>5) Interoperability with UBL
>   Target audience: standards bodies
>   Level of compliance: low
>
>   Scenario:
>
>   Another standards body is developing in a different area and is
>   not interested in generating schemas yet wants to incorporate
>   UBL components into their library for use in a wider
>   application.  Both the integrity of the UBL and target standard
>   namespace would be preserved - no jury rigging of making
>   namespaces work within a namespace.
>
>   Use case:
>
>   For basic components, this is very useful.  UBL address, for
>   example.  Everyone uses/needs address.  If this was needed in a
>   different standard, the standards body could take this UBL
>   comopnent and incorporate it into their own normative output
>   and then call their output a standard.  Then their users can
>   use UBL components to create their documents.  This could
>   happen with small components (BIEs in Reusable), or with the
>   entire document ABIEs.
>
>   Additional thoughts:
>
>    - Does NDR address this wthen they talk about modules?
>
>    - Prescibing for standards bodies is different than
>      prescribing in UBL for users of UBL.
>
>    - In this case, to make a change we'd need to go outside of
>      UBL and incorporate bi-directional changes - non-UBL things
>      could also go into UBL.
>
>    - Rules may not be the same - every standards body that
>      imports UBL may have their own; may have other namespaces
>      being imported that don't comply with namespace rules; so
>      need to build modularly enough to reduce barriers to
>      importing UBL which will overall help with harmonization as
>      well.
>
>    - This importing is the same as what we're doing with
>      reusable.
>
>6) Contextualizing UBL (subset)
>   Target Audience: other language speakers
>   Level of compliance: -
>
>   Scenario:
>
>   UBL changed for context (eg. Japanese - translated tag names)
>   which has validity in this implementation.  Namespace would
>   remain the same, otherwise would end up with something similar
>   to a proprietary non-compliant schema.
>
>   Use Case:
>
>   Japanese and Chinese Localization SCs
>
>   Additional thoughts:
>
>    - Need to have a way to allow these diffrences to be expressed
>      in the standard.
>
>==================================================================
>
>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.
>
>
>Atomic Model of Customisation and Compliance 
>--------------------------------------------
>
>   A user is free to use all BIEs in UBL 1.0, but in use/reuse,
>   schema fragements must remain intact - no modification of
>   namespace, local names, etc. within adopted BIE 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.
>
>   Using RN for an example:
>
>   (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.
>
>   If an organization tries to build a document (eg. warehouse) it
>   can either 1) extend building on top of what we already have
>   with the closest matching document (eg. delivery can start off
>   with dispatch, add on what they want to add, and document what
>   they want to remove); or 2) Look at individual BIEs found in
>   the Despatch docuemnt and pickout the ones they want to use
>   then construct under their own namespace the two delivery
>   addresses, signature fields, etc. However at those points where
>   they use any part of UBL they can't touch those (eg. schema
>   fragements).  if they change this in any way they are not
>   compliant.
>
>   This is not creating a document within a document.  If you use
>   the original document you inherit it wholesale; otherwise, you
>   just pull out the pieces, but don't change the pieces.  The
>   reusability of UBL will be at the atomic level (ABIEs/BBIEs).
>   This allows you to verify if one is compliant or not.  You can
>   check mechanically - this is straightforward.  Can even check
>   manually.  Where UBL is not used the namespace can be
>   different, but where UBL is used, the namespace must remain
>   UBL.
>
>   This is in the instance space so far, so doesn't conflict with
>   ndr compliance - it's a different dimension.  This doesn't say
>   how to lay out schemas, though.  One could still have instance
>   compliance and still have local variables.
>
>   This is keyed to Types, not elements.  Instead of CC
>   compliance, this raises it up a level to ABIE/BBIE compliance.
>
>   This is instance-based in that the resulting instances must
>   look exactly the same as ones generated with UBL.  There must
>   be no mistake about that.  It will be easy to verify.
>
>   This is talking about instance-based atomicity.  Because of
>   this atomicity there is now a way to check if the instance is
>   compliant, regardless of how you design the schemas.  Can also
>   still implement schema validation on the fragments if desired.
>   For example, if the UN was to create many classes of
>   international documents based on UBL they would all carry a UN
>   namespace except where they reused UBL components - those would
>   be copies wholesale of the UBL component with UBL namespaces.
>
>   Compliance/conformance usually applies to specific releases,
>   and then compatibility comes between releases of
>   compliant/conformant schemas/artifacts if the rules applied are
>   in themselves backward compatible.
>
>==================================================================
>
>III. Miscellaneous
>
>   Issues surfaced:
>
>    - Versioning and back compatability: if keep to ndr rules that
>      every version has to be in nameapce, we've lost back
>      compatibility unless UBL evolves compatibly.  we may have to
>      extend with namespaces because of the namesapce rules.  we
>      may need to preserve name of tag forever.
>
>    - Need to clarify between valid, compliant, compatible.
>
>    - Need to document all this information.
>
>    - Use of the NDRs: there is a compliance that is not tied to
>      the NDRs because the rules in themselves don't guarantee
>      compliance - there are some rules which if not followed can
>      still end up with valid instances, and other rules that when
>      followed and still produce non-validating instances.  The
>      rules need to be reviewed to determine which of them impact
>      validation and how this effects interoperability and
>      conformance/compliance, since NDR compliance does not equate
>      to UBL interoperability/compliance.  The ones that do will
>      be the rules that tools will need to have built in.  The
>      current state of NDRs is not self-consistent enough for
>      public tools use.  Also, current rules create a
>      non-compatible situation with respect to namespace use
>
>    - The current restriction on namespaces seems to be too tight
>      for implementors to remain compliant.  It may be necessary
>      to organize the NDRs into those relevant for internal
>      development and those relevant for external development.  We
>      need metadata about NDRs.
>
>    - Need distinction between evolution, extension, addition, ...
>      what kinds of things can these concepts apply to?  what
>      things can you extend?  library, ndr, schema ?
>
>    - Overall, we want to restrict the improper usage of UBL but
>      create mechanisms that will allow the liberal use of
>      extension.
>
>   Initial questions raised:
>
>      "What does it mean to be UBL compliant?"
>
>      "Does UBL compliance equate to CCTS compliance?"
>
>      "What is the difference between contextualization and
>      customization?"
>
>      "Where is the use case analysis of context and
>      customization?"
>
>      "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?"
>
>      "To what degree should a tool allow relaxing of NDR rules?"
>
>
>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.
>
>  
>