Re: [bdxr] BDE-question

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

At 2015-05-29 09:10 +0000, Martin Forsberg wrote:
> I?ve followed the work on BDE carefully and also
> presented an update on the project to the
> CEN-BII team. The progress and result looks very
> good, completely in line with the requirements specification we?ve published.

Thank you for that confirmation!

> I?ve understood that the BDE PayloadContent
> element now allows for non-xml (but escaped) text such as base64 encoded data.

Indeed.  In the latest draft I have included the
content of the example instance within the body
of the specification so that a reader need not
have to open any of the artefacts to see an illustration of this.

> This is very useful if you want to transmit an
> ASIC-container or other non-XML based payload.
> SBDH doesn?t allow for this (the content type is
> ?element-only?) and that is a significant
> drawback. The implementers of SBDH would need to
> create an inner envelope which would allow non-element content .

Understood.

> So, my question is ? would it be useful to have
> an attribute or element on the Payload or
> PayloadContent indicating the encoding type of
> the payload data? Essentially informing the
> receiver about the fact that the payload is non-xml (in case non-xml is used)?

Would not the InstanceSyntaxID BIE provide
sufficient information to the recipient?

InstanceSyntaxID
Payload. Instance Syntax Identifier. Identifier
0..1
Identifier. Type
BBIE
Identifies the syntax that the payload instance is expressed in.

This was intended for the purpose you've identified.

Hmmmmmm ... perhaps I should modify the example
instance as follows, where I personally make the
assumption to use a MIME type (such a decision
would be agreed upon by trading partners in
advance of encoding messages with syntax
identifiers; I wouldn't want my example to be
considered as the only way to identify the payload as being simple text):

<?xml version="1.0" encoding="UTF-8"?>
<Envelope xmlns="http://docs.oasis-open.org/bdxr/ns/bde/1.0/Envelope";
  xmlns:ebc="http://docs.oasis-open.org/bdxr/ns/bde/1.0/BasicComponents";
  xmlns:eac="http://docs.oasis-open.org/bdxr/ns/bde/1.0/AggregateComponents";>
  <ebc:ID>123</ebc:ID>
  <ebc:CreationDateTime>2015-02-08T20:34:00-04:00</ebc:CreationDateTime>
  <eac:FromParty>
    <ebc:ID>A</ebc:ID>
  </eac:FromParty>
  <eac:ToParty>
    <ebc:ID>B</ebc:ID>
  </eac:ToParty>
  <eac:Payload>
    <eac:PayloadContent>
      <myDocumentHere>
        <myElement>My Content</myElement>
        <myElement>My Content</myElement>
        <myElement>My Content</myElement>
      </myDocumentHere>
    </eac:PayloadContent>
  </eac:Payload>
  <eac:Payload>
    <ebc:InstanceSyntaxID schemeID="MIME">text</ebc:InstanceSyntaxID>
    <eac:PayloadContent>
Non-XML payload here, with sensitive characters
escaped such as &amp;, &lt; and ]]&gt;.

Any text, provided it has been escaped, can be included in a payload.
    </eac:PayloadContent>
  </eac:Payload>
  <eac:Payload>
    <eac:PayloadContent>
      <myOtherDocumentHere>
        <myOtherElement>My Content</myOtherElement>
        <myOtherElement>My Content</myOtherElement>
        <myOtherElement>My Content</myOtherElement>
      </myOtherDocumentHere>
    </eac:PayloadContent>
  </eac:Payload>
</Envelope>

Per RFC1767 there is a MIME type for EDI content
(an example that was brought up in the meeting
where someone asked if we could put escaped
EDIFACT content in the envelope, which we can):

   Application/EDI-X12
   Applicatin/EDI-consent

But, again, MIME isn't obligated to be used

Please let me know if you identify any concerns
regarding our proposed approach.

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