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
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.
>
>
>
