Re: [ubl-comment] Maybe I have misunderstood it...

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

Thank you, David, for this input.

I have distilled your comments as follows and provided an initial 
response in an attempt to give you a timely answer.  This response 
will be reviewed by the UBL Technical Committee for any additional comment.

(1) - the representation of positive/negative responses

It is intended that the <cac:DocumentResponse> ASBIE capture the 
representation of the response:

http://docs.oasis-open.org/ubl/os-UBL-2.1/mod/summary/reports/UBL-AllDocuments-2.1.html#Table_ApplicationResponse.DocumentResponse

The structure of the ABIE is outlined here:

http://docs.oasis-open.org/ubl/os-UBL-2.1/mod/summary/reports/UBL-AllDocuments-2.1.html#Table_DocumentResponse.Details

... in which one finds the response ASBIE to this ABIE:

http://docs.oasis-open.org/ubl/os-UBL-2.1/mod/summary/reports/UBL-AllDocuments-2.1.html#Table_Response.Details

... in which one can place the response code as defined by the users 
of the customization of UBL.

The UN/CEFACT Core Component Type for codes defines optional 
BBIE-level metadata in attributes that can be used to identify the 
code list associated with the coded value.

(2) - the lack of standardization of the use of any coded values in UBL

The absence of any specification of particular code lists in the UBL 
conformance clauses is intentional.  The committee has imposed no 
constraints of any kind on the values of codes (other than the 
lexical constraint of being a normalized string, per the UN/CEFACT 
Core Component Type).

Accordingly, the conformance clauses state only conformance to schema 
constraints and additional document constraints not expressed in the schema:

http://docs.oasis-open.org/ubl/os-UBL-2.1/UBL-2.1.html#S-CONFORMANCE

Understanding the important role of code lists, UBL 2.1 includes a 
non-normative annex describing one possible method of a user 
community imposing coded value constraints on top of the 
conformance-related document structure constraints:

http://docs.oasis-open.org/ubl/os-UBL-2.1/UBL-2.1.html#A-UBL-2.1-CODE-LISTS-AND-TWO-PHASE-VALIDATION

In support of this candidate method, and to demonstrate its use, the 
committee has created genericode representations of popularly-used 
code lists users may find helpful in their use of UBL.  The 
demonstration environment includes an XSLT stylesheet that 
incorporates the provided selection of illustrative code lists.

Early in the development process the UBL committee determined that 
code lists are sufficiently varied and sufficiently fluid so as to be 
applied differently in all contexts of use of UBL worldwide and over 
time.  Especially given how code lists can change from their 
publisher, and can change in which codes are used perhaps on a daily 
basis, baking in coded values into the UBL schemas would make the 
schema expressions extremely fragile.

Whereas, by divorcing coded values from the conformance schemas, one 
can claim at all times schema structural conformance to the read-only 
published specification with full backward compatibility to future 
revisions of UBL.  Our committee responsibility ends at the 
schemas.  And to be consistent, *all* coded values are external to 
the schemas, even for concepts not likely to change (latitude and 
longitude directions for an example of this).

This puts the onus on the user community to define for their 
particular community what the coded value constraints shall be and 
how they are to be validated.

. . . . . . . Ken

At 2017-09-28 12:32 +0100, David Goodenough wrote:

> but the ApplicationResponse object strikes me as strangely disappointing.
>
>
>
> Looking at the flow diagrams, there are references to negative and positive
>
> responses, this is not explicitly represented in the ApplicationResponse or
>
> any of its sub-objects.
>
>
>
> There also does not seem to be a standard set of StatusReasonCodes or
>
> ResponseCodes. Surely there are a bunch of specific responses, many of
>
> which are shown in the flow diagrams, which could, or rather should be
>
> defined for interoperability. There might be supplimentary information
>
> which is implementation specific and might be used by humans to solve
>
> a problem, but the basic logic flow states should be defined in the
>
> standard.
>
>
>
> There is a DocumentStatusCode, but that is only used for transport
>
> related activities.
>
>
>
> Given that I am new to this lot, it might be that I have simply not found
>
> the code lists, but there is actually no reference to either StatusReasonCode
>
> or ResponseCode in the:-
>
>
>
> Universal Business Language Version 2.2
>
> Committee Specification Draft 01 /
>
> Public Review Draft 01
>
> 21 December 2016
>
>
>
> and no genericode definition for either that I can find, and no codes
>
> listed on the flow diagrams.
>
> David
>
> (Confused of Broadwell)


--
Contact info, blog, articles, etc. http://www.CraneSoftwrights.com/o/ |
Check our site for free XML, XSLT, XSL-FO and UBL developer resources |
Streaming hands-on XSLT/XPath 2 training class @ US$45 (5 hours free) |