[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-comment] Proposal for UBL 2.2: Document Version History (delta + cause)
Good evening, Joseph. The UBL TC has discussed your submission to the UBL Comment List and tracked it with this ticket: https://issues.oasis-open.org/browse/UBL-24?filter=12972 We recognize that document change history information can be valuable when analyzing the ways a UBL document has changed in its life cycle. We note this is a horizontal requirement suitable for users of all UBL documents who want to track changes and history. It seems eminently suitable for following the incremental assembly of the UBL document. However, we do not consider such maintenance information to be "business document information" per se, and so we feel it is not suitable to be modeled as part of the UBL Common Library of business objects that use the UBL vocabulary namespaces. The information seems orthogonal to the business document as the "final" business document that results from an assembly of many parts and steps remains the identical business document with either the presence or the absence of its own change history. Moreover, while the change history might be very important to the creator of the document, it may be less important or not important to some or all of the recipients of the document. They may be focused solely on the business content of the business document regardless if its creation history. Finally, the committee noted your citation of existing vocabularies you think may have the suitable semantics to be expressed, but are already being expressed in XML schemas. It would make no sense to mimic the existing vocabulary, construct for construct, in the UBL common library namespaces and attempt to maintain equivalence (through mandatory translation) to any changes in the foreign vocabulary that is on a different development track than UBL. We have concluded that the UBL extension point, available for all UBL documents as the first child of the apex document element, is the most suitable home for the information you are describing. Your task, then, would be to create the UBL extension scaffolding within which instances of these particular foreign vocabularies can live inside of any and every UBL document. This addresses the horizontal applicability of non-business object information, and supports vocabularies that have their own active governance. The instance change information can then be added to or extracted from under the extension point of any arbitrary UBL document in a deterministic fashion and manipulated by existing tools already familiar with the non-UBL vocabularies. We invite you to consider such an approach when using UBL. You are welcome to post again to the UBL Comment List with your observations. On behalf of the committee I thank you for your interest in UBL! . . . . . . . Ken At 2016-05-31 09:52 -0400, Joseph Potvin wrote:
RE: Deadline for submission of changes for UBL 2.2
XALGORITHMS PROPOSAL TO OASIS FOR UBL 2.2:
DOCUMENT VERSION HISTORY (DELTA + CAUSE)
Submitted by Xalgorithms Foundation
<https://www.xalgorithms.org/>https://www.xalgorithms.org/
Contact: Joseph Potvin, Executive Director,
Mobile: 819-593-5983, <mailto:jpotvin@xalgorithms.org>jpotvin@xalgorithms.org
This text arises from 100% free/libre/open
source work-in-progress by Xalgorithms
Foundation
<https://www.xalgorithms.org/>https://www.xalgorithms.org/
and is dual-licensed under the "OASIS Feedback
License" and the "Creative Commons Attribution 4.0 International License".
1. PREAMBLE
The purpose of this proposal is to intiate
discussion about the utility of including
document version history and associated
causality within UBL, and to explore alternative
approaches to implementing this capability.
Xalgorithms Foundation would contribute
technical specifics to move this proposal
rapidly forward in accordance with feedback and
guidance from the UBL community and its TC.
We anticipate that implementation would require
a new namespace, several new elements, and a new
document type. Our proposal makes reference to
some non-UBL XML schemas to illustrate our
intent with examples. However it remains to
determine which elements of their approaches and
particular technical structures from these references might be adapted to UBL.
The business reason for adding document version
history and associated causality are described
here with regard to the UBL invoice, which is a
particular requirement of the
authors:Â
<https://docs.oasis-open.org/ubl/os-UBL-2.1/xsd/maindoc/UBL-Invoice-2.1.xsd>https://docs.oasis-open.org/ubl/os-UBL-2.1/xsd/maindoc/UBL-Invoice-2.1.xsdÂ;
 However the authors anticipate that this
capability might be most usefully considered as
applicable to several UBL document types.Â
2. EXAMPLE: UTILITY OF INVOICE VERSION HISTORY
Within a set of rules, a buyer and a seller
trade goods and services at a price. Some of
those rules come into a transaction from sources
other than the buyers and sellers
themselves?from governments, looyalty programs,
data providers, accounting standards, and
financial intermediaries. The velocity of each
transaction, as in air travel, depends
significantly on the â??baggage handling
efficiencyâ?? associated with it. The more
time and effort that a transaction requires to
be executed as a whole, including all the
baggage that must go with it, the higher its
procedural cost will be. Transaction time and
cost can be dramatically reduced by automating
the computational rules invoked by each
transaction, such as taxes, duties, price
benchmarks, loyalty programs, data constraint
notifications, reporting, messaging, etc.
Consider a network service that accepts UBL
invoice data, then finds and fetches external
rules, and issues an updated UBL invoice with an
extended data package that includes all
applicable taxes, duties, points, a price
coefficient if algorithmic pricing is specified
in the contract, and so on. The output would be
a more complete UBL invoice document.
Version history and change causality of an
invoice document are not the same as the status
of the invoice in the context of busine workflow
(e.g. whether it is paid). The UBL schema
already accommodates business processes. The
present proposal is focused upon the incremental
assembly of the invoice itself. Following are some considerations:
- An invoice is dynamic until until a
transaction is executed against it, at which
point it becomes an audit record with legal significance.
- The invoice must remain atomic so that element
changes can be separately tracked. It should be
possible to sign only parts of an invoice, and
to accept multiple signatures. (A blockchain ledger might make sense here.)
- A new top level element could be "change
history" in a new namespace, the use of which would be optional.
- Documentation of change causality can be added
to each subsequent version, as part of the new version.
3. DELTA: XML DOCUMENT VERSION HISTORY
Caveat: The references in this section describe
multiple ways of implementing XML document
version history. The present proposal does not
yet recommend an optimal versioning solution for UBL.
Sonawane, V. R., & Rao, D. R. (2015). A
Comparative Study: Change Detection and Querying
Dynamic XML Documents. International Journal of
Electrical and Computer Engineering, 5(4), 840.
<https://www.iaesjournal.com/online/index.php/IJECE/article/viewFile/7702/4049>https://www.iaesjournal.com/online/index.php/IJECE/article/viewFile/7702/4049Â;
Lead author: "Vijay Sonawane"
<<mailto:vijaysonawane11@gmail.com>vijaysonawane11@gmail.com>
"Dynamic XML documents are applicable in many
fields of information management and create the
demand that it should support multi-version
documents. Therefore it is necessary to store
different versions of XML documents with time.
Storage of all the versions of an XML document
is not an effective solution as it increases the
duplication and makes searching and querying
harder on growing document. So it is essential
to find techniques to store and detect the
changes in multiversion XML documents. Its also
important to find schemes to efficiently execute
the cross version queries over dynamic of XML
document. ... Delta document records the changes
between two consecutive versions. Using delta
one can easily locate its previous version so it
has been considered that the delta approach is
superior to the object referencing approach.
More from these authors:
<https://scholar.google.com/citations?user=6T4PSqEAAAAJ&hl=en>https://scholar.google.com/citations?user=6T4PSqEAAAAJ&hl=en
The sequence of changes involved in advancing
from one version to the next might be important
to the outcome. "Synchronized Multimedia
Integration Language" (SMIL) Timing is the
W3C-recommended mark-up structure for attributes
that specify an element's timing behavior.
Despite the context difference here, SMIL might
generally indicate a useful approach for our
present
purpose.Â
<https://www.w3.org/TR/REC-smil/smil-timing.html>https://www.w3.org/TR/REC-smil/smil-timing.html
4. CAUSE: DOCUMENTING REASONS FOR CHANGE WITHIN XML DOCUMENT VERSION HISTORY
Changes to primary data in an invoice (in whole
or in part) between a buyer and a seller due to
the application of adjustments such as taxes,
duties, price benchmarks, loyalty programs,
conditional notifications, etc. must be
efficiently documented. Essential data about
change causality must be provided in a
transformation record, and paired with the
subsequent invoice version. At the users'
option, the transformation record could be
"adjacent to" or "intrinsic to" the invoice document.
4.1 DOCUMENTING THE CAUSE OF A CHANGE
Potentially, the cause of a change could be
documented with reference to WHO, WHAT, WHEN, WHERE, WHY and HOW data:
- WHO: The identity (in a UBL way) of the change
agent. In addition to the entity making the
change, this might include the identity of an
automated system acting on that entity's behalf.
- WHAT: Literally, the change.
- WHEN: Timestamp.
- WHERE: Location data of the change agent (IP address; URI; geodata).
- WHY: Reason(s) for the change. Depending on
context, this could be a structured reference to
an algorithm that's been applied, or a free form comment.
- HOW: Method used to make the change.
Caveat: We do not yet know if the following
references bring far more complication than
necessary, or if they indicate an elegant and
pragmatic way to accommodate the inherent breadth of this requirement.
Nested Context Language (NCL 3.0) is a
declarative language for hypermedia authoring
that might provide a suitable XML Schema for
documenting reasons for change. It was created
in a different domain of application from UBL,
but possibly the XML expression requirement is similar:
<http://www.ncl.org.br/>http://www.ncl.org.br/
http://www.ncl.org.br/en/schemasxml#CausalConnector
<http://www.ncl.org.br/en/schemasxml#NCL30CausalConnector>http://www.ncl.org.br/en/schemasxml#NCL30CausalConnector
http://www.ncl.org.br/en/schemasxml#NCL30CausalConnectorFunctionality
Following are some excerpts from selected papers:
"It also presents how ... requirements could be
offered in an XML-based language, in order to
improve its expressiveness, presenting elements
and attributes that could be incorporated in its
DTD ... specifying n-ary relationships
expressing causality or constraint among
components." ... "In causal relationships,
some action is executed when a specific
condition is satisfied." ... "The action element
represents actions that should be executed in
the target end points of a causal link. They can
be simple (simple-action) or compound
(compound-action). Simple actions can be applied
to end points that define presentation events
(prepare, start, stop, pause, resume, abort) or
to end points that define attribution events
(relative-assign, absolute-assign, enable,
disable, activate). Those values are defined
through the action-name attribute of the simple-action element."
Source:
<http://www.telemidia.puc-rio.br/sites/telemidia.puc-rio.br/files/2000_11_antonacci.pdf>http://www.telemidia.puc-rio.br/sites/telemidia.puc-rio.br/files/2000_11_antonacci.pdf
"In order to provide the necessary semantics for
defining causal or constraint relationships
among events, a hypermedia connector may be
specialized in a causal or constraint connector.
A causal hypermedia connector has two types of
roles: condition and action. A constraint
hypermedia connector has just one type of role, condition."
Source:
<http://webmail.midiacom.uff.br/downloads/pdf/muchaluat-saade_2004.pdf>http://webmail.midiacom.uff.br/downloads/pdf/muchaluat-saade_2004.pdf
"This work focuses on the use of links for
representing referential and synchronization
relationships. The traditional referential
relationship, usually represented by a link, can
be considered a special case of a causal
synchronization relationship, specifying that an
action must be fired when a condition is
satisfied. In this particular case, the
triggering condition occurs at a
non-deterministic time instant: the user
selection of an anchor. Therefore, the
definition of hypermedia links can be
generalized to model other types of
synchronization relationships"... "XConnector
(17) is an XML-based language providing the
definition of xconnector elements. Each
xconnector defines a set of roles (that will be
played by participating resources in a
relationship) and how they actually interact,
through a child element called glue."
Source":
<http://www.telemidia.puc-rio.br/sites/telemidia.puc-rio.br/files/2002_10_muchaluat.pdf>http://www.telemidia.puc-rio.br/sites/telemidia.puc-rio.br/files/2002_10_muchaluat.pdf
"The final document generated after the template
is processed will contain A, B and also
synchronization links giving the sequential semantics."
Source:
<http://www.telemidia.puc-rio.br/sites/telemidia.puc-rio.br/files/2002_10_muchaluat.pdf>http://www.telemidia.puc-rio.br/sites/telemidia.puc-rio.br/files/2002_10_muchaluat.pdf
4.2 DOCUMENTING THE SOURCE ALGORITHM USED IN A CHANGE
Caveat: These preliminary documentation
requirements for computational algorithms in the
e-commerce domain arise from work-in-progress by Xalgorithms Foundation.
Each externally-obtained algorithm that is
invoked to alter data in a UBL document can be
expressed with the following data elements:
- A uniform resource identifier (URI) of the
source respository of the external algorithm
(discovered, for example, through an IETF RfC
3375 and RfC 3401/3402 conformant registry),
including ongoing version history of the algorithm
- A legal entity identifier (LEI, conformant
with ISO 17442:2012) controlling the external
algorithm ("control" is meant as specified in
UNCITRAL Model Law on Electronic Transferable Records)
- A concise table-oriented expression of the algorithm
- Terms of use of the algorithm (conformant with the SPDX Specification)
References:
Internet Engineering Task Force (IETF)
References for the Xalgorithms Federated Registry
RfC 3375 â??Generic Registry-Registrar Protocol
Requirementsâ??
<https://www.ietf.org/rfc/rfc3375.txt>https://www.ietf.org/rfc/rfc3375.txt
RfC 3401 & 3402 â??Dynamic Delegation Discovery
Systemâ??
<http://www.rfc-base.org/rfc-3401.html>http://www.rfc-base.org/rfc-3401.htmlÂ;
http://www.rfc-base.org/rfc-3402.html
XML Signature WG
<https://www.w3.org/Signature/>https://www.w3.org/Signature/
& https://datatracker.ietf.org/wg/xmldsig/charter/
"ISO 17442:2012 specifies the elements of an
unambiguous legal entity identifier (LEI) scheme
to identify the legal entities relevant to any financial transaction."
-
<http://www.iso.org/iso/catalogue_detail?csnumber=59771>http://www.iso.org/iso/catalogue_detail?csnumber=59771
- https://www.gleif.org/en/lei-focus/what-is-an-lei
- <https://www.gleif.org/>https://www.gleif.org/
United Nations Conference on International Trade Law (UNCITRAL)
<http://www.uncitral.org/uncitral/en/commission/working_groups/4Electronic_Commerce.html>http://www.uncitral.org/uncitral/en/commission/working_groups/4Electronic_Commerce.html
Table-Driven Design
<https://www.techopedia.com/definition/30408/table-driven-design>https://www.techopedia.com/definition/30408/table-driven-design
Software Package Data Exchange (SPDX) Specification\
<https://spdx.org/>https://spdx.org/
****************
Joseph Potvin
Executive Director, Xalgorithms Foundation
Mobile: <tel:819-593-5983>819-593-5983
<mailto:jpotvin@xalgorithms.org>jpotvin@xalgorithms.org
https://www.xalgorithms.org
-- Check our site for free XML, XSLT, XSL-FO and UBL developer resources | Streaming hands-on XSLT/XPath 2 training @US$45: http://goo.gl/Dd9qBK | Crane Softwrights Ltd. _ _ _ _ _ _ http://www.CraneSoftwrights.com/o/ | G Ken Holman _ _ _ _ _ _ _ _ _ _ mailto:gkholman@CraneSoftwrights.com | Google+ blog _ _ _ _ _ http://plus.google.com/+GKenHolman-Crane/posts | Legal business disclaimers: _ _ http://www.CraneSoftwrights.com/legal | --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]