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


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

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

Subject: Use cases (UBL compliance)

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



[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


   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

   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

    - 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  


   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

    - 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

3) UBL label compliance - evolution of UBL
   Target audience - all industries/uses
   Level of compliance - full (beyond NDR)


   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

    - 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


   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

   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

    - 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


   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

    - This importing is the same as what we're doing with

6) Contextualizing UBL (subset)
   Target Audience: other language speakers
   Level of compliance: -


   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

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):

         .. atomic content structure .. 
         <RN:MainPart> ... </RN:MainPart>
         <RN:SubPart> ... </RN:SubPart>

   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

   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

   (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:

       <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:MainPart> ... </RN:MainPart>
         <RN:SubPart> ... </RN:SubPart>

   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

   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

   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

   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

   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

      "Where is the use case analysis of context and

      "How much can a user change in the UBL schemas and still be
      'UBL compliant'?"

      "How do we ensure compatibility / interoperability of UBL

      "How to implement customization and contextualization and
      still keep compliance between releases?"

      "To what degree should a tool allow relaxing of NDR rules?"

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