[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (UBL-24) Comment submission re: document version history
[ https://issues.oasis-open.org/browse/UBL-24?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=62561#comment-62561 ]
Ken Holman commented on UBL-24:
-------------------------------
This is a very interesting requirement and I can imagine that some UBL users might find it very useful. I'm a big believer of version control and revision maintenance in software development. I can see its use for instance development.
I agree with the statement in the preamble (Section 1) that this is a horizontal requirement many might find useful for any UBL document type. But version history, while useful, is more of a maintenance and management mindset and not the same kind of information as the business information found in the UBL vocabulary. Yes, what is being maintained and managed is business information, but the information being added to the business document is the maintenance and management information.
Accordingly, I see the need as orthogonal to the UBL vocabulary and its intended use: the UBL document is a business document representing a static piece of information. The "final" invoice is what is going to be sent from sender to receiver, and the receiver's business process will be acting on the "final" values found in the instance. These final values are no different than if they were the first or only values ever used in the instance. The history of their derivation is certainly useful to a document's creator, but I would think it would be less useful to a document's recipient. This is referred to as the "more complete UBL invoice document" (Section 2).
This is underscored in summarizing the focus of the proposal (Section 2) as the "incremental assembly of the invoice itself". Again, we are talking here about the assembly, it just happens to be of a business invoice (or order, or waybill, or whatever). The proposal continues "until a transaction is executed against it, at which point it becomes an audit record with legal significance". I'm presuming there would then be no more revisions. Certainly if the document is digitally signed there can be no more information added.
Moreover, the requirement is put forward with "multiple ways of implementing XML document version history" (Section 3) but without making a specific recommendation. The Nested Context Language cited (Section 4.1) looks very interesting. It seems to be a large and detailed vocabulary with well-defined semantics.
Whichever XML vocabulary is chosen, the namespaces, labels and associated semantics would not readily be re-framed using the UBL namespaces and new labels. Tools recognizing any existing vocabulary would not recognize UBL labels and namespaces. The committee has chosen the CCTS methodology for modelling the business constructs in the business documents, and these are not business constructs, they are maintenance and version control constructs.
Therefore, I feel strongly the UBL extension point is the ideal construct with which to implement this requirement. I don't think it requires any modifications for UBL 2.2, and it could be wholly backwards-compatible to existing implementations of UBL 2.1 and UBL 2.0. All that would have to be modelled would be extension scaffolding within which the foreign vocabulary would be carried.
A parallel situation has cropped up in some pre-award discussions where a requirement associated with the European Commission was considered for presentation as a pre-award modification to UBL:
https://lists.oasis-open.org/archives/ubl-pre-award/201605/msg00009.html
In that post I posited that that, also, is best suited as an extension because of the same properties:
* not all users of the UBL document are interested in the organizational details
* shoe-horning each and every W3C construct into brand new UBL constructs would be a management headache
* existing users recognizing the W3C vocabulary would be challenged to find those semantics in contrived UBL constructs
* the organization details do not add anything to the business part of the UBL document satisfied by identifying parties simply as parties and their properties as identified in the UBL common library
This is the example attached and note that I've created only a simple one-element scaffold that surrounds the result ontology instance of some query:
https://lists.oasis-open.org/archives/ubl-pre-award/201605/msg00009/TenderPartyExampleW3CExtension.xml
Consider for both requirements (this ticket and the pre-award requirement) that our committee has already published a "standardized extension" of some scaffolding carrying information expressed using a foreign namespace. This could be mimicked in creating a new extension for revision maintenance.
The W3C signature extension introduced in UBL 2.1 is also fully backwards compatible with the UBL 2.0, it incorporates an existing W3C XML vocabulary and it has the scaffolding of UBL vocabulary constructs providing association information not expressed in the W3C vocabulary:
http://docs.oasis-open.org/ubl/os-UBL-2.1/xsd/common/UBL-CommonSignatureComponents-2.1.xsd
http://docs.oasis-open.org/ubl/os-UBL-2.1/xsd/common/UBL-SignatureAggregateComponents-2.1.xsd
http://docs.oasis-open.org/ubl/os-UBL-2.1/xsd/common/UBL-SignatureBasicComponents-2.1.xsd
Here is an example Invoice with the W3C signature information and information from two other dummy namespaces embedded under the extension point:
http://docs.oasis-open.org/ubl/os-UBL-2.1/xml/UBL-Invoice-2.0-Enveloped.xml
Similarly, a new extension for revision maintenance would likely be backward compatible and readily deployable to existing implementations of UBL 2.0 and 2.1, not needing to wait for UBL 2.2 to get the functionality.
In conclusion, I propose we respond to the submitter with the encouragement for them to create, document and manage a UBL extension point for instance change tracking and version control and publish its availability on http://ubl.xml.org for UBL users. Whether we choose to include this (or any extension developed outside of the committee) in a future distribution would be the subject of consideration at the time that it is submitted to the committee through the comment list. I don't think we have the need to contribute our resources to this at this time.
I look forward to other opinions from committee members.
. . . . . . . . . Ken
> Comment submission re: document version history
> -----------------------------------------------
>
> Key: UBL-24
> URL: https://issues.oasis-open.org/browse/UBL-24
> Project: OASIS Universal Business Language (UBL) TC
> Issue Type: Task
> Reporter: Ken Holman
> Assignee: Ken Holman
> Priority: Minor
>
> This comment was posted and needs to be addressed one way or the other for UBL 2.2:
> https://lists.oasis-open.org/archives/ubl-comment/201605/msg00011.html
--
This message was sent by Atlassian JIRA
(v6.2.2#6258)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]