Re: [bdxr] Groups - BDE requirements v.1.0 wd 01.docx uploaded

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

At 2015-02-22 23:38 -0800, Kenneth Bengtsson wrote:
> Document Name: 
> <https://www.oasis-open.org/apps/org/workgroup/bdxr/document.php?document_id=55132>BDE 
> requirements v.1.0 wd 01.docx

While working on the edits, I've changed a couple of requirements 
currently worded as mandatory to be optional as found in the earlier drafts.

Also, I've made the wording consistent where mandatory is "must 
contain..." and optional is "must be possible to...".  I've also 
removed use of the word "optional" which is redundant with the new 
wording for optionality.

> BDE-02
> A BDE must carry an unambiguous version number.

"It must be possible to specify the BDE version of the envelope."

> BDE-05
> It must be possible to optionally include information in a BDE that 
> unambiguously identifies the originating party.

"It must be possible to include information in a BDE that 
unambiguously identifies the originating party."

> BDE-06
> It must be possible for the originating party to digitally sign a BDE.

"It must be possible for the originating party to digitally sign a 
BDE with any number of signatures."

> BDE-07
> A BDE must be able to contain one or more payloads.

"A BDE must contain one or more payloads."

> BDE-08
> Each payload in a BDE must be uniquely identifiable.

"It must be possible to uniquely identify each payload in a BDE."

This was optional in earlier drafts as an identifier isn't needed if 
there is only one payload, and trading partners may be satisfied 
agreeing on ordinal position identification of payloads.

> BDE-10
> It must be possible to state a reference of a BDE, such as to a 
> specific agreement, case, document, prior correspondence, etc.

"It must be possible to identify the reference to a relevant 
resource, such as a specific agreement, case, document, prior 
correspondence, etc."

Writing up this one was tricky for me.  It now seems to me that this 
"relevant reference" could be numerous, and not just optional.  There 
might be many items to point to.  But I can't just change the 
cardinality to "0..n".

Following document engineering principles Tim taught me, then, that 
makes this an ABIE, with repetition on the ASBIE that points to 
it.  Why?  Because in the future there might be other properties 
about the reference, making it a complex construct.  It might require 
a version number, or an effective date, or some other property of 
this relevant reference.

The only BBIEs that can be "many" should be the BBIEs that have many 
facets, such as language translations.  Most description fields have 
"..n" in order to provide for multiple languages.

The parallel where Tim taught me about this in UBL's address 
structure where we need address lines.  Rather than create a BBIE for 
Address Line with "0..n", there is an ASBIE for Address Line and the 
Address Line ABIE has a single BBIE that is mandatory.  There are no 
other pieces of information (yet) about an address line, but it is a 
conceptual construct that could have other properties.  You can see 
how it is modelled in the Address here, with the eaddress line only 
three lines down:

http://docs.oasis-open.org/ubl/os-UBL-2.1/mod/summary/reports/UBL-AllDocuments-2.1.html#t-CommonLibrary-39

The kicker is, if we finalize BDE 1.0 with the reference as a BBIE 
then we can't, in the future, change it to an ASBIE/ABIE.

I propose we follow suit with the Address Line and create the ABIE 
"External Reference" with the "1" BBIE named "ID", and then the 
"0..n" ASBIE "Relevant External Reference" pointing to it.

Shall I postpone that proposal until the first review, or should I 
put this in right away?

> BDE-14
> It must be possible for a BDE contain payloads that have been 
> encrypted, as long as they have been expressed in such a way as to 
> not interfere with the XML scheme.

Just a couple of grammatical changes:

"It must be possible for a BDE to contain payloads that have been 
encrypted, as long as they have been expressed in such a way as to 
not interfere with the XML schema."

I think all of the other definitions are consistent.  I'll now 
continue the revisions to map the information items to each of the 
requirements.

Please let me know your thoughts on the modeling change I'm proposing 
above.  I think it is important.

. . . . . . . . Ken

--
Check our site for free XML, XSLT, XSL-FO and UBL developer resources |
Free 5-hour lecture:  http://www.CraneSoftwrights.com/links/video.htm |
Crane Softwrights Ltd.             http://www.CraneSoftwrights.com/o/ |
G. Ken Holman                    mailto:gkholman@CraneSoftwrights.com |
Google+ profile:       http://plus.google.com/+GKenHolman-Crane/about |
Legal business disclaimers:     http://www.CraneSoftwrights.com/legal |


---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com