[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: To do: Re:RE: Regarding the Thursday ebXML Conf Call
Subject
To do: Re:RE: Regarding the Thursday ebXML Conf Call
Starts:
Priority:
Due:
Type:
Group To Do
|-------------|
| [ ] Repeats |
|-------------|
Owner:
Melanie Kudela/Princeton/UCC
Assignments already sent
To:
dick@8760.com, drummond@onramp.net,
ebXML-Transport@lists.oasis-open.org, kit@mitre.org
cc:
rawlins@metronet.com
|------------------|
| [ ] Mark Private |
|------------------|
Others cannot see any details about this event.
|---------------|
| [ ] Notify me |
|---------------|
Have Notes notify you before the event.
Categorize:
Description:
__________________
What was presented to us during our call today was that you were
selecting
mime as "the" ebXML solution. If that is not the case, then we don't have
an
issue. Although I personally can't understand why anyone would want to use
an
antiquated technology such as e-mail to forward XML, especially in a
business to
business exchange, I do see the need to accomodate folks desires. If on
the
other hand, you are selecting mime as "the" ebXML solution, then I think
that
you will loose participation and support of the bulk of the XML community.
Rik, it appears the Requirements group needs to be made aware that people
will want to send XML documents via E-mail and E-mail is not a W3C
specification.
Dick
Hi,
Regarding the EBXML Transport/R/P conference today, my understanding is
that the group is pursuing a mime-based envelope structure? I mentioned
that at the EBXML Requirements teleconference, which happened to be
immediately after the TRP teleconf, and they weren't happy about that
direction and hoped the TRP group will revisit that decision. In
particular, it was suggested that there is an EBXML requirement for all
EBXML specifications to be compliant with W3C technical specificatons.
(Though Mike Rawlins said that the transport may be an exception.) I
cite the relevant section from the EBXML Requirements document, which is
to be released to the full EBXML body for review this Monday.
Kit.
1.2.1 ebXML Vision
The ebXML vision is to deliver:
"A single set of internationally agreed upon technical specifications
that consist of common XML semantics and related document structures to
facilitate global trade."
This single set of ebXML technical specifications will create a Single
Global Electronic Market. To create this single global electronic
market, this single set of ebXML technical specifications:
- is fully compliant with W3C XML technical specifications holding a
recommended status,
- provides for interoperability within and between ebXML compliant
trading partner applications,
- maximizes interoperability and efficiency while providing a
transition path from accredited electronic data interchange (EDI)
standards and developing XML business standards, and
- will be submitted to an appropriate internationally recognized
standards body for accreditation as an international standard.
Perhaps we should do a better job of drawing a clear distinction between
the outer wrapper of an ebXML message (which is where MIME comes in) and
the various components of the message. As I recall we agreed that one of
the key components of an ebXML message is the header. The header will be an
XML document and the header analysis currently under way will presumably
spell out a generic header and an extension mechanism for handling optional
or domain specific headers. There will presumably be a number of other
components (e.g. routing info, manifest ...) that will all be in XML. I
thought we agreed that we want to deal with message payloads that may or
may not be XML documents. Again assuming I am on the right track, then the
question remains. How do we glue multiple objects, some in XML and others
in XYZ format, into a discreet message. I think MIME may serve a very
narrow purpose, i.e. as the glue. Is there an alternative glue standard
that is pure XML *and* can be described using an XML schema language ? Just
because multiple objects are glued together using MIME, does not
subsequently bind us to an SMTP infrastructure. I think we all agree that
we would like to take a transport neutral approach. Am I correct in
assuming that the purist view is that we should only deal with XML payloads
?
__________________
> The problem that is being addressed by mime encapsulation only arises
when
> there is a need to transmit multiple XML Message bodies and provide
support
> for arbitrarily large binary objects (i.e. images). Most participants
seemed
> to agree that this type of mixed transmission would not be well suited to
> further encapsulation in another XML envelope. A case was sited were only
> one of the messages is desired out of a potentially large multi-part
block.
> With most parser implementations a pure XML encapsulation would only
allow
> the use of SAX parsing to avoid processing the entire message.
I am not sure that this would be possible, but just thinking loudly. Would
this work?
For large files:
1) Compose a XML msg where payload is XML as well. Payload is user specific
so it might be that some of them would need to transfer 30MB image file.
That file could be embedded (CDATA) or it could be referenced (URI) or
whatever else.
2) Send it via ANY reliable protocol. Who cares about packets; requirement
is that the whole XML msg is going to be delivered to the receiving end.
3) Use XML parser on receiving side. If SAX, go to manifest and find that
there is a big file in the payload. Save it somewhere. If DOM good luck?
For recursive "EnvelopeAsAPayload" pattern:
1) On receiving end while digesting manifest, discover that payload has
another envelop(s). Process those recursively.
In both cases MIME is possible, but not required. Anyway, this might be a
good candidate for an early prototype (proof of concept)?
Nikola
__________________
Nikola:
<SNIP>
> With most parser implementations a pure XML encapsulation would only
allow
> the use of SAX parsing to avoid processing the entire message.
</SNIP>
Whoa!! This is bogus. In the context of valid XML, both SAX and DOM must
parse the entire docoment to compare it with the schema/DTD to ascertain
whether or not it is valid. A SAX parser can stop parsing if it encounters
syntax error in well formed /valid XML. You are talking about parsing, not
handlers for encountered instances.
<Nikola>
I am not sure that this would be possible, but just thinking loudly. Would
this work?
For large files:
1) Compose a XML msg where payload is XML as well.</NIKOLA>
This would constitute an XML message. It is redundant to mention an XML
message and XML payload.
<NIKOLA> Payload is user specific
so it might be that some of them would need to transfer 30MB image file.
That file could be embedded (CDATA) or it could be referenced (URI) or
whatever else.</NIKOLA>
First of all, you cannot declare binary data as CDATA. Any handlers will
puke on the input. "Embed" is a member function of the XLink:show
namespace
which issues a direction to include the referenced data into the document.
If the XLink:actuate is selected to "onLoad", your handler will try to
interpret pure binary data. The MIME type for XML is Text. 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.
<NIKOLA>
2) Send it via ANY reliable protocol. Who cares about packets; requirement
is that the whole XML msg is going to be delivered to the receiving
end.</NIKOLA>
I believe that TCP/IP - HTTP is the basis for which this will be built.
The
protocol MUST be O/S and Platform independant. We cannot accept anything
less. HTTP has many of the built in error handling routines we need for
ebXML and is also easily integrated with security protocols.
<NIKOLA>
3) Use XML parser on receiving side. If SAX, go to manifest and find that
there is a big file in the payload. Save it somewhere. If DOM good
luck?</NIKOLA>
Which XML Parser? If you are referring to the Perl parser (XML::Parser),
the parser is built on top of James Clark's XPat parser in C. The parser
does not actually embed the link. It just reads the text. It is the
handlers that act upon the parsed XML that perform this functionality.
Therefore, a link to a 30 mb file will parse just as quickly as a link to a
1 mb file.
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.
__________________
Nikola:
<SNIP>
> With most parser implementations a pure XML encapsulation would only
allow
> the use of SAX parsing to avoid processing the entire message.
</SNIP>
Whoa!! This is bogus. In the context of valid XML, both SAX and DOM must
parse the entire docoment to compare it with the schema/DTD to ascertain
whether or not it is valid. A SAX parser can stop parsing if it encounters
syntax error in well formed /valid XML. You are talking about parsing, not
handlers for encountered instances.
<Nikola>
I am not sure that this would be possible, but just thinking loudly. Would
this work?
For large files:
1) Compose a XML msg where payload is XML as well.</NIKOLA>
This would constitute an XML message. It is redundant to mention an XML
message and XML payload.
<NIKOLA> Payload is user specific
so it might be that some of them would need to transfer 30MB image file.
That file could be embedded (CDATA) or it could be referenced (URI) or
whatever else.</NIKOLA>
First of all, you cannot declare binary data as CDATA. Any handlers will
puke on the input. "Embed" is a member function of the XLink:show
namespace
which issues a direction to include the referenced data into the document.
If the XLink:actuate is selected to "onLoad", your handler will try to
interpret pure binary data. The MIME type for XML is Text. 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.
<NIKOLA>
2) Send it via ANY reliable protocol. Who cares about packets; requirement
is that the whole XML msg is going to be delivered to the receiving
end.</NIKOLA>
I believe that TCP/IP - HTTP is the basis for which this will be built.
The
protocol MUST be O/S and Platform independant. We cannot accept anything
less. HTTP has many of the built in error handling routines we need for
ebXML and is also easily integrated with security protocols.
<NIKOLA>
3) Use XML parser on receiving side. If SAX, go to manifest and find that
there is a big file in the payload. Save it somewhere. If DOM good
luck?</NIKOLA>
Which XML Parser? If you are referring to the Perl parser (XML::Parser),
the parser is built on top of James Clark's XPat parser in C. The parser
does not actually embed the link. It just reads the text. It is the
handlers that act upon the parsed XML that perform this functionality.
Therefore, a link to a 30 mb file will parse just as quickly as a link to a
1 mb file.
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.
Message text written by "Duane Nickull"
><NIKOLA> Payload is user specific
so it might be that some of them would need to transfer 30MB image file.
That file could be embedded (CDATA) or it could be referenced (URI) or
whatever else.</NIKOLA>
First of all, you cannot declare binary data as CDATA.<
>>>>>>>>>>
Technically the way to do this is using UUENCODING - but that makes for a
massive file, but doable.
Since the URI is the best way to go - you can cache content, you can ping
headers via tcp/ip to get size and date/time stamp, before you decide to
haul it over the wire.
30MB files are not unusual for medical imagery - in fact full body MRI's -
150MB,
and CatScans, Heart Scans, where there is a real time element as well -
bigger.
I think we should ensure these can be handled - since bandwidth is
increasing
orders of magnitude. So five years from now - this stuff will be small
potatos.
The business need drives the technical solution requirements as it should.
DW.
Message text written by "Duane Nickull"
><NIKOLA> Payload is user specific
so it might be that some of them would need to transfer 30MB image file.
That file could be embedded (CDATA) or it could be referenced (URI) or
whatever else.</NIKOLA>
First of all, you cannot declare binary data as CDATA.<
>>>>>>>>>>
Technically the way to do this is using UUENCODING - but that makes for a
massive file, but doable.
Since the URI is the best way to go - you can cache content, you can ping
headers via tcp/ip to get size and date/time stamp, before you decide to
haul it over the wire.
30MB files are not unusual for medical imagery - in fact full body MRI's -
150MB,
and CatScans, Heart Scans, where there is a real time element as well -
bigger.
I think we should ensure these can be handled - since bandwidth is
increasing
orders of magnitude. So five years from now - this stuff will be small
potatos.
The business need drives the technical solution requirements as it should.
DW.
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>
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>
<David>
> First of all, you cannot declare binary data as CDATA.<
>
> >>>>>>>>>>
> Technically the way to do this is using UUENCODING - but that makes for
a
> massive file, but doable.
</David>
<http://www.ucc.ie/xml/>
(It would, however, be possible to include a text-encoded transformation of
a binary file as a CDATA marked section, using something like UUencode with
the markup characters ] and > removed from the map so that they could not
occur and be misinterpreted.)
</http://www.ucc.ie/xml/>
<David>
> I think we should ensure these can be handled - since bandwidth is
> increasing
> orders of magnitude. So five years from now - this stuff will be small
> potatos.
</David>
I agree. And, five years from now we might have many other things improved
(X..., ...). And we hope ebXML will be everywhere.
<David>
> The business need drives the technical solution requirements as it
should.
</David>
Absolutely. Many times implementers give solutions (how) without justifing
it (why).
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC