[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [ UBL coordination] Use cases (UBL compliance)
As requested in last Friday's coordination call, here is a resend of the original thoughts stemming from a discussion of this subject in the TTSC in December. In Friday's call we agreed on the need to continue inquiry and discussion into this topic in order to come to some conclusions by the release of UBL 1.0 final in February. There has been some further discussion of this topic in various SC calls, and some email on the TTSC list. Thanks, Anne -------- Original Message -------- Subject: [ubl] Use cases (UBL compliance) Date: Fri, 12 Dec 2003 16:46:24 -0800 (PST) From: jon.bosak@sun.com Reply-To: jon.bosak@sun.com To: ubl@lists.oasis-open.org 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): .. atomic content structure .. ... ... 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: .. atomic .. .. atomic .. .. atomic .. .. atomic .. .. atomic .. ... ... 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]