Re: [ubl-dev] Applicability of 'Forwarding instructions' in the absence of an ordering context

[jon.bosak@sun.com]

[stephengreenubl@gmail.com:]

| I have some reservations about how general statements in the main
| body of the UBL 2 spec relate to conformant use of the UBL
| document types, in comparison to the weight of the schemas and
| their definitions.

There's no comparison between the two.  The process descriptions,
are, strictly speaking, semantic; that is, they provide the
semantic context for the schemas.  Part of the answer to the
question "What's an Invoice?" is that it's the thing that fulfills
the role of Invoice in the relevant process diagrams.  But the
description does not limit your use of an Invoice document.  This
is stated at the beginning of Section 4 of the UBL 2.0 Standard:

   The processes described in this section, and the business rules
   associated with them, define a context for the use of UBL 2.0
   business documents. They are normative insofar as they provide
   semantics for the UBL document schemas, but they should not be
   construed as limiting the application of those schemas.

The distinction is critical from the viewpoint of standards
development because it makes clear that UBL is not an initiative
to define process conformance; if it were, we'd still be years
away from producing anything useful.  It's an initiative to define
document conformance.

| As such I would interpret UBL's conformance requirements (still to
| be fully elaborated in the forthcoming Customisation Guidelines)
| as implying that as long as the use of the documents doesn't
| contravene the document definitions found in the schemas then
| reuse of the documents is OK without change when the instance
| structure, semantics and syntax conform to the schemas.

It's actually even looser than that.  The Customization Guidelines
are still a work in progress, but we've arrived at a very clear
distinction between *conformance* and *compatibility.*  From the
latest draft:

   2.1.1. UBL Conformance

   UBL conformance at the instance and schema level means there
   are no constraint violations when validating the instance
   against a standard UBL schema. A UBL conformant instance is an
   instance that validates against a standard UBL document
   schema. A UBL conformant schema is a schema that will validate
   only UBL conformant instances.

   2.1.2. UBL Compatibility

   To be UBL compatible means to be consistent with the principles
   behind UBL's models or their development. These principles are
   defined in the ebXML Core Component Technical Specification and
   the UBL Naming and Design Rules. While we cannot assume
   conformance and interoperability of these customized documents,
   we can expect some degree of familiarity through the re-use of
   common objects.

| I don't think it has yet been made a firm conformance requirement
| that a document's use match the UBL 2 spec process diagram and
| description.  Otherwise this would need to be added to the
| Custmisation Guidelines document and I don't think this has been
| included in the latest draft.

Adherence to the process diagrams will never be a UBL conformance
requirement.  As noted in the definitions above, UBL conformance
is a strictly mechanical concept that has only to do with
validation against the Standard schemas.  Compatibility, on the
other hand, does depend on semantic alignment, and defining this
dependence cleanly is still a near-term work item for the
Customization Guidelines.  Whether adherence to the process
diagrams is a requirement for compatibility (as opposed to
conformance) is an interesting question, and I thank the group for
raising it as an issue.

Jon