RE: [bdxr] BDE - presentation in the BII architecture team

[Kenneth Bengtsson <kbengtsson@efact.pe>]

Thank you Martin and Ken.

I support having the signature as a qualified element at the end of the structure.

With regards to the point that the BDE may facilitate unwanted content to be distributed, my feeling is that this might be out of scope for this specification. Especially if to keep with the design requirement that the BDE must be payload agnostic. We can make a note of it as an item for discussion at this week's call.

Best regards,

Kenneth

________________________________________
From: bdxr@lists.oasis-open.org [bdxr@lists.oasis-open.org] on behalf of G. Ken Holman [gkholman@CraneSoftwrights.com]
Sent: Tuesday, February 17, 2015 10:52 AM
To: Martin Forsberg; bdxr@lists.oasis-open.org
Subject: Re: [bdxr] BDE - presentation in the BII architecture team

Thank you, Martin, for bringing our work to the attention of the group.

At 2015-02-17 15:30 +0000, Martin Forsberg wrote:
>I have today presented the BDE-work to CEN/WS
>BII architecture team. We looked at the BDE
>draft and it seems to fully meet the
>requirements previously captured by BII. The
>e-tendering team will make an assessment to
>verify that it also covers the needs specific
>for the pre-award processes but the first
>impression is that BDE draft probably supports
>what’s needed. The ePrior-team from the European
>Commission will also make a similar assessment.

I look forward to their final findings.

>A couple of observations were made:
>·       The cardinality of the
>Envelope/Payload/PayloadContent is currently set
>to 1..n. From the BII-perspective, 1..1 would
>make more sense, but it might be that we haven’t
>understood the requirement behind the
>possibility. (This comment does not relate to
>the Envelope/Payload-element, which should be 1..n as already defined.)

Pending agreement with the rest of the committee,
I agree it should have been 1..1 (and I see the
copy/paste error that I made that resulted in this being wrong).  Well spotted!

>·       Regarding the specific question Ken
>sent:
><https://lists.oasis-open.org/archives/bdxr/201502/msg00006.html>https://lists.oasis-open.org/archives/bdxr/201502/msg00006.html.
>It was the BII-team´s view that having the
>signature as a qualified element in the end of
>the structure was the preferred approach.

So noted.  We will include this endorsement in our discussions.

>·       It was also concluded that the BDE may
>give possibilities which are not necessarily
>wanted in some communities (such as bundling an
>Invoice and an Order in the same envelope which
>would not be ok in PEPPOL). This should be
>handled by additional policies/rules created by
>those communities, essentially customizations to BDE.

I agree ... it would be a challenge (impossible?)
to try and address that requirement generally as a set of document constraints.

>·       The reference to the xmldsig listed in
>section 1.3 should be
><http://www.w3.org/TR/xmldsig-core1/>http://www.w3.org/TR/xmldsig-core1/.

Hmmmmmm ... that means a change to the schemas to
incorporate the 1.1 schemas ... does anyone know
if there are any changes needed to the XAdES
schemas for the 1.1 schemas?  In my own work I've
only ever dealt with the 1.0 schemas.

Note that the document still needs to be revised
with respect to the prose.  I have made an
effort, but writing prose is not my strength and
the text should be replaced by better writing.

>Please find attached the presentation in pptx-format.

Thank you, again, for your efforts in this regard!

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


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php