Re: [bdxr] BDE requirements

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

Thanks, Kenneth, for the feedback!

At 2015-02-23 18:07 -0500, kenneth@alfa1lab.com wrote:
> Yes, I agree with everything you wrote above. My question was if 
> "PayloadInstanceEncryptIndicator" could be replaced with a 
> "PayloadInstanceEncryptionMethod". The 
> PayloadInstanceEncryptionMethod would be not-present if no 
> encryption was used, and in case encryption was used would hold the 
> algorithm used for encryption.

Forgive me for not expressing myself, but I understood your 
suggestion.  My point was that I wasn't sure the particular 
encryption used was important to the envelope as it seemed a bit 
private to me.  But if you think it is important, then I have no 
problem with the envelope including an indication of the encryption method.

But by conflating the two concepts into one data item, do we then 
need to standardize some value for "unspecified encryption type" for 
those users who do not wish to reveal the kind of encryption in 
use?  I guess that remains an issue with me.  Would we specify the 
"unspecified" value, or would trading partners?

Would you agree to having both information items you cite in your 
question?  We would have both PayloadInstanceEncryptionIndicator to 
indicate that the payload is encrypted, and then, if desired, the 
user can populate PayloadInstanceEncryptionMethod separately.

Then we aren't conflating two concepts into one item and somewhat 
"forcing" the issue.  The item is easily added to the data model, and 
it doesn't take anything away from what CEN/BII Architecture reviewed 
last week.

> I'm not sure I understand or see the use case where both the 
> ProfileID and ServiceID would be present, but I'm not religiously 
> opposed to having both of them in the spec either. If you believe 
> that the necessity is there then no objection from me.

Ah, but I was only giving you my interpretation of why I thought 
CEN/BII had the two requirements MSGE-16 and MSGE-15 ... they seem to 
think that MSGE-15 is insufficient and MSGE-16 is needed:

"""
MSGE-15 When a payload instance is used for a single business 
document, it should be possible to state the Business Transaction it 
represents, the Syntax Message in which it is expressed, the set of 
business rules (Customization) applicable and the Profile in which it is used.

MSGE-16 When a payload instance is used for a single business 
document, it should be possible to identify the service appropriate 
for processing of the business document. I some cases these may be 
calculated based on information covered by MSG-15 (e.g. PEPPOL), but 
this it not necessarily always the case.
"""

Personally, I can't see it ... but it has come up in their 
requirements and I would worry that we are taking something away from 
what they've already assessed as suitable.

> Is there any scenario where the business envelope software would 
> need to know the CustomizationID? Will anyone ever need to know the 
> CustomizationID except for understanding how to read the business 
> document? For service routing etc. we already have the ProfileID and ServiceID.

Well, perhaps the recipient needs to know the CustomizationID to know 
which encryption method is used between trading partners in a 
community when the encryption method is not specified.

But that is just speculation.

I understand my position of "copy the metadata into the envelope so 
that the recipient can see the metadata without seeing the document" 
does not indicate any kind of boundary.  And I didn't think the 
metadata would go all the way to the Invoice ID and the Tax Point 
Date and those other metadata-kind-of-thingies that we have under the 
document element.  But I did think that that kind of business context 
metadata common to every document (in UBL's case) would be useful, if 
not to the envelope software then to the recipient.  And the 
recipient will have different envelope software than an intermediary 
would have.

Those fields of metadata are distinguished in that they are common to 
every document in the suite ... so I think they have a different 
status than other children of the document element.  And I think they 
can be exposed in the envelope without revealing anything at all 
about the contents of other fields.

> So are we introducing a requirement for a third party to get 
> involved in the creation of the envelope (in certain use cases at least)?

Requirement?  No.  I'm just thinking that vendors can offer agent 
services to users so that users don't have to implement it 
themselves.  The documents can be sent using their own trusted 
transmission to their agent to then forward on the public networks.

> > The editing task includes changing all the hyperlinks from the components
> > to the requirements.
>
> Anything I can do to help you just let me know!

Thanks, but I see that the XML is straightforward, so I think I can 
use some regular expressions.

BTW, I like the way that you suggest in the spreadsheet the 
positional importance of the primary payload.  Simple.  Well 
done.  That prevents the community having to address what I brought 
up in the conference call when two payloads both indicate that they 
are primary: "It is up to the user community to define the 
interpretation of more than one payload indicating that it is 
primary."  Now they don't have to do that.

So as an intermediate step I've updated the model by adding the 
encryption method and removing the primary indicator:

https://docs.google.com/spreadsheets/d/1NE5XNAReiiI0AfZD1uWB2x5gCzU4BKI23gUdGrvpEGk/view

Of course anything can still change if you don't agree with my comments above.

. . . . . . . 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