[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl] Use cases (UBL compliance)
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. > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]