[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ebxml-msg] Status of Messaging spec vote
Phil,
Please see my comments below
Cheers,
Christopher Ferris
Architect, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
phone: +1 508 234 3624
Phil Griffin
<phil.griffin@asn To: Christopher B Ferris/Waltham/IBM@IBMUS
-1.com> cc: ebxml-msg@lists.oasis-open.org
Subject: Re: [ebxml-msg] Status of Messaging spec vote
08/02/2002 11:34
AM
Christopher B Ferris wrote:
> All,
>
> In addition to Doug's comments on payload neutrality (e.g. the payload
> can be *anything* the business partners agree to use and mutually
> understand)
> I would point out that there is no requirement that formal XML schema
> validation
> be applied to the SOAP part of the message either. The specification
makes
> it
> clear what the interpretation of the received SOAP header blocks in the
> message
> mean in the context of an exchange between partners sharing a CPA. There
is
> no
> requirement for PSVI contribution to understand the contents of the SOAP
> envelope.
If no schema validation is required, I am puzzled
as to why a particular schema is required. Please
<cbf>
What do you mean by "required". The ebMS specification builds on
SOAP1.1 which is formally described by an XML Schema schema, but which
does not impose any requirement for XML Schema schema validation because
we don't make use of the PSVI. It is simply a tool that allows one to
describe an XML document's structure in a formal and machine processable
manner.
ebMS uses XML Schema in that manner. Neither does the specification
preclude or prevent an implementation from leveraging XML Schema
schema validation should they so choose.
</cbf>
explain. Doug asserts "We had to choose a single
technology because of the need to identify in
the message its relevant schema".
If schema validation is not required, then it would
seem that your specification could be changed, with
no loss of interoperability, to allow ASN.1 schema
to be used.
<cbf>
The ebMS specification need not be changed. You can write an
ASN.1 module that can validate the XML instance artifacts the
ebMS specification defines by translating the ebMS XML Schema
into ASN.1:
http://asn1.elibel.tm.fr/xml/#schema-mapping
Nothing in the ebMS specification is preventing anyone
from doing that. Again, the ebMS specification does not
impose any constraints on how an implementation chooses
to effect the processing defined, that is strictly up to
the whim, ingenuity, and creativity of the implementer.
</cbf>
> Secondly, Griffin Consulting's comments suggest that ebMS would
disbenefit
> potential
> users of the (proposed) standard working in resource constrained
> environments.
>
> It isn't made clear from the comment whether the nature and scope of
> "resource
> constrained environments" applies to cell phones, PDAs, and/or toasters
or
> simply
> to older model desktop PCs that might be used by SMEs. If the former is
> what was intended,
> it isn't at all clear to me that ebXML was ever intended to address such
> severely resource
> constrained devices. If the latter, then I am at a loss to understand how
> to respond
> without further substantiation of the claim. Resource constrained in what
> manner(s)?
> To what degree(s)? What evidence exists that supports the claim that the
> proposed
> standard could not be implemented in those environments?
My meaning of resource constrained applies to several
environments. Remote and mobile devices is one, and I
do not agree with your implication (as I read it) that
cell phones and PDAs are not viable business devices.
These are constrained ultimately by battery life, as
they continue to grow in speed and processing power.
<cbf>
I don't dispute that cell phones, PDAs and the like
are valuable business *devices*. I was simply stating
that it was not our objective to produce a unbiquitous
messaging protocol for all possible *devices*. Rather,
to produce a specification that enabled *businesses*
to exchange messages between themselves, via the
internet. Addressing severely resource constrained
devices was not a requirement that the TC considered.
Nor was it ever raised as a requirement during the
18 month period of the public ebXML initiative or the
more than 14 month period which has passed since
the ebXML initiative transferred stewardship of
the ebXML infrastructure specifications to OASIS.
</cbf>
Memory constrained devices such as smart cards are
another environment. These too are growing in size
and power, but the real estate is expensive, and
multiple applications now compete for it. For large
populations, say in the hundreds of millions needed
for payment card customers, avoiding the high end
state of the are cards makes more applications cost
effective.
<cbf>
Same comment as above.
</cbf>
Finally, there are high volume transaction systems.
Here message size and the quantities of messages
that can be processed per unit time are important
considerations.
<cbf>
Right, and over time, with performance optimizations
the processing capacity will increase just as it has
for other technologies that were deemed to have poor
performance characteristics. However, this has little
to do with the ebMS spec per se, and more to do with
XML. If you are disputing our choice of use of XML as a
technology, then that is a separate issue altogether.
The ebXML initiative, sponsored by UN/CEFACT and OASIS,
that brought you the ebMS specification was called ebXML
for a reason.
</cbf>
And security is an important consideration in all
of these environments.
<cbf>
But, of course! I still fail to see what that has to
do with your comment accompanying your NAY vote. You seem
to be suggesting that we go back to the drawing board and
do it all over again using ASN.1. This is quite unlikely.
Once the W3C completes its work on the SOAP1.2 specification,
which is XML Infoset based, then we can begin work on a
new version of the ebMS specification that leverages SOAP1.2
and its architectural foundation (that the responsibility of
a node is to convey the XML Infoset, not necessarily as XML1.0
pointy brackets syntax, but other possibly more efficient
expressions.
Until then, this is what we have.
</cbf>
Phil
> Even if ebMS *did* require PSVI contribution to understand the contents
of
> a SOAP envelope
> (which as I have indicated is *not* the case), there are effective
> optimizations that can be applied that
> eliminate the need for full XML Schema validation using a standard XML
> Schema processor such
> as Apache's Xerces that can yield an equivalent result.
>
> Cheers,
>
> Christopher Ferris
> Architect, Emerging e-business Industry Architecture
> email: chrisfer@us.ibm.com
> phone: +1 508 234 3624
>
>
> Doug Bunting
> <db134722@iplanet To:
ebxml-msg@lists.oasis-open.org, phil.griffin@asn-1.com
> .com> cc:
> Subject: Re: [ebxml-msg]
Status of Messaging spec vote
> 08/01/2002 07:53
> PM
>
>
>
>
>
> All,
>
> We at Sun previously contacted Phil Griffin to ask for a clarification of
> his comment. Quoting from an email in that discussion:
>
> | I'm not entirely certain ebXML Messaging prevents use of ASN.1 in
> | the ways Phil would like. The specification is entirely payload
> | agnostic and goes so far as to recommend the SOAP Body not be used
> | to contain the application content. No requirement for an XML
> | Schema description of the payload or payloads exists. In this
> | respect, the existing specification remains schema independent.
> |
> | If he would like to utilize ASN.1 to validate, encode and sign the
> | message header itself, he's correct that he's out of luck. We had
> | to choose a single technology because of the need to identify in
> | the message its relevant schema. I don't understand a way to make
> | this aspect of ebXML Messaging schema independent. Yes, we could
> | have defined the concepts at a higher level and bound them to SOAP
> | but the additional layer wouldn't have helped with
> | interoperability concerns. If this is Phil's primary area of
> | concern, he should vote "no" on the SOAP 1.2 specification at the
> | W3C.
>
> Phil, would you care to comment further for the benefit of this group? I
> may not have been clear in my comments above: ebXML Messaging defines a
> wire protocol for carrying some semantic / descriptive information
between
> two systems. That wire protocol is schema dependent to the extent it
> leverages the SOAP protocol. That extent does not cover the associated
> business documents or (more generically) payload content. ebXML
Messaging
> is completely payload agnostic and schema independent for those payloads.
>
> thanx,
> doug
>
> <snip/>
>
>
>
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC