I just did some digging and I see that a MIME subtype is mandatory and not optional:
https://tools.ietf.org/html/rfc2045 (Section 5.1) ... and so I suppose my example would have to change to be as below. Note that in my example the trading partners are assuming that in the absence of an instance syntax specification that XML is assumed. . . . . . . . . . Ken <?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/plain</ebc:InstanceSyntaxID> <eac:PayloadContent> Non-XML payload here, with sensitive characters escaped such as &, < and ]]>. 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> At 2015-05-29 07:05 -0400, G. Ken Holman wrote: 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): ... 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