[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
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?"
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]