[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [resend of December document] compliance scenarios
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 developmers 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 whomever recieves 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 partenrs, and still
want their instances to be valid to anyone else using UBL -
to guartantee that other users of UBL can use their documents.
- Sofwtare developer that nees 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 partipular 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 restriciton reguired,
how does the receiver, who doens't know about that restriction,
still able to validte 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 algortitm to validate this restricted schema.
This is a 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) Subset of Extend and/or restrict UBL
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 diffrent 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. One level above CC reuse/interop.
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 standars 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 naems)
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-basaed 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 fullfill
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 namepsace 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 ljust 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 instacne space so far, so doens't conflict with
ndr compliance - it's a different dimension. This doens'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 automicity. 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 whoelsale of the UBL compoent 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. Mischellaneous
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 eveloves compatibly.
we may have to extend with namespaces because of the namesapce rules.
we may ned to preserve name of tag forever.
- neeed 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 namesapce 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 distiction between evolution, extension, additon, ...
what kinds of things can these concepts appy 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]