RE: RE: Regarding the Thursday ebXML Conf Call

["Dick Brooks" <dick@8760.com>]

Nick and I are working very hard to produce samples for everyone to review
and scrutinize. Please gives us a couple of days to gather our thoughts,
prepare the samples and present to the group. Then we can discuss the issues
of binary payloads, header representation, et al from a common base of
understanding.

Thanks,

Dick Brooks
http://www.8760.com/


-----Original Message-----
From: owner-ebxml-architecture@lists.oasis-open.org
[mailto:owner-ebxml-architecture@lists.oasis-open.org]On Behalf Of
Nikola Stojanovic
Sent: Thursday, March 02, 2000 9:19 PM
To: ebXML-Transport@lists.oasis-open.org
Cc: ebXML-Architecture@lists.oasis-open.org
Subject: Re: RE: Regarding the Thursday ebXML Conf Call


Thanks Duane.
I hoped that you'd check the scenario. However, as you can conclude reading
the first paragraph, we might have two requirements to fulfill:

1)
<Duane>
> Third - I
> cannot think of any rational how a 30mb image file can possibly be
> considered part of an XML e-business transaction.  It could be the
"subject"
> of the transaction, but XML is a text language.
</Duane>

It looks to me that there might be a business transaction that needs to
include very large files, which would mean that delivery of the file
(embedded, referenced, attached, ??? via payload) has to be part of the
agreed document exchange. This would entail that it might require (among
other things) later auditing as well.

2)
<NIKOLA>
1) Compose a XML msg where payload is XML as well.
</NIKOLA>

<Duane>
This would constitute an XML message.  It is redundant to mention an XML
message and XML payload.
</Duane>

Messages might need to include other messages (possible recursively). In
that case one of the possible candidate solutions was to put lower level
envelopes inside the higher level payloads. If you don't treat payload as an
XML content then how you parse, handle, ... your payload? And sometimes 1)
your payload needs to (embed, reference, ???) large files.

> If you are building the message blocks for transporting,  the construction
> of the messaging can be a very important aspect for efficiency.  I do not
> think you should force people to use either DOM or SAX as part of a design
> rule.

I agree. DOM and SAX were just mentioned and used as possible candidate
methods. MIME was also one of the possible candidates. It would be ideal
that we just have "XML". However, how we format an ebXML msg would influence
what method we use in order to be efficient and vice versa. As always in a
real world, your "Data Model" is not independent of how you "Process your
Data".

<Nikola>
Anyway, this might be a good candidate for an early prototype (proof of
concept)?
</Nikola>