SV: Concern with basic ebXML TRP Syntax/Semantics

["Greg FitzPatrick" <gf@medianet.org>]

This note illuminates the problems of bridging between MIME and XML within
one particular standards effort.


I (Greg FitzPatrick) work with the SKiCal WG

http://www.skical.org/index.html

Our charter is to take the pioneering vCal/iCal standardization work carried
out within the IETF CALSCH WG, as defined in the core model:

http://www.imc.org/rfc2445

and extend it to a universal online catalog standard (SKiCal) for the
publishing of public events including the access coordinates of
physical-world resources as expressed in addresses, Geos, opening times,
telephone times, and a great deal more as defined here:

http://www.ietf.org/internet-drafts/draft-many-ical-ski-01.txt

As most of you with desktop calendars well know iCal is a "mime type thing".
For the present  SKiCal is extended within iCal by the mechanism of
X-properties as defined in RFC2445.

For the last 18 months the CALSCH WG has been indecisively hashing about the
"XML thing"

Tersely expressed, the problem is "extending with out breaking".  Since the
natural flow of most  standards activity is to reach a minimal, manageable
core and then improve upon it.  (note: improving and extending are not
synonymous).

Constantly newcomers to the WG have asked how we could ignore the advantages
of Namespaces, Schemas, conditional qualifying through the use of nested
properties, web-publishable -machine-readable objects and so on, by not
jumping on the XML bandwagon.

The answer was and still is that since XML is so "unconstrained" in its
invitation to extensibility  it could seriously damage the uncommonly high
level of interoperability existing within the Internet calendaring and
scheduling sector.  Face it, there is a lot more mime type out there than
there is XML.

With greatest respect for that opinion, the SKiCal WG and those within the
CALSCH WG that support SKI, still are quite enamored with the advantages
described above.  Particularly the ability to access multiple schemas,
nomenclature repositories, and typing mechanisms.

In February last, I launched an initiative to create a joint IETF-W3C WG to
bridge the iCal work into the XML world.  (note: this was not unique there
are precedents) This imitative received the immediate support of Tim B-L,
but a luke warm reception from the IETFers, and nothing has come of it.

Consequently our limited-resource working group has to support development
on two fronts simultaneously and that aint fun.  If we are lucky there will
be enough support for officially merging iCal and SKiCal at
IETF-Philadelphia and then taking a new look at the XML Bridge.

Here are our arguments for why RFC2445 in mime-type just doesn't cut it for
our purposes in the long run;

http://www.metamatrix.se/presentationer/html/tutorial/chap1.htm

Now there are good strategies for separating semantic developments from
syntactic developments and hanging semantics on appropriate syntaxes as
those syntaxes reach some sort of maturity, but I would counter that there
is no such thing as a clean cut between semantics and syntax.  And of course
the differences between XML and mime far exceed syntax.

So, it is a rocky road for us and I believe a rocky road for ebXML.

Of course this will all be resolved in one way or another:-)

I would be happy to answer any questions or provide more pointers if
desired.  Good luck to all of us!


Greg



> -----Ursprungligt meddelande-----
> Från: owner-ebxml-requirements@lists.oasis-open.org
> [mailto:owner-ebxml-requirements@lists.oasis-open.org]För Kit
> (Christopher) Lueder
> Skickat: den 6 april 2000 23:44
> Till: Christopher Ferris
> Kopia: ebXML-Transport@lists.oasis-open.org; ebxml-requirements
> Ämne: Re: Concern with basic ebXML TRP Syntax/Semantics
>
>
> Thanks, but you need to take this back to the ebXML requirements group,
> for alignment. I am cc'ing them on this.
> Kit.
>
> Christopher Ferris wrote:
> >
> > Kit,
> >
> > While I wasn't able to participate the the f2f meeting in
> > Dallas and can't speak to the finalized packaging minutia
> > I can address this from the perspective of one of the
> > members of the packaging sub-team.
> >
> > We discussed this in depth in the packaging sub-team.
> > We felt that there was inadequate support in the various
> > W3C XML recommendations to support our requirements
> > which follow:
> >
> > - Able to handle large documents
> > - Able to envelope any document type
> > - Minimize intrusion to payload (special encodings or alterations)
> > - Minimize potential for abnormal termination caused by envelopes
> > - Facilitate a migration path for existing installed base and
> technologies
> > - Low processing overhead
> > - Support for recursive documents
> > - Able to preserve digital signatures
> > - Able to unambiguously identify signed data
> >
> > To quote Dick's minutes of our sub-team meeting:
> >
> > <db>
> > Both MIME and XML were discussed relative to these requirements. It
> > was the groups consensus that MIME was better positioned today to
> > meet the stated requirements. However, it was also believed that XML
> > would mature as a packaging technology and the ebXML group should
> > continue to monitor XML's progress for possible inclusion at a
> later date.
> > It was also believed that Microsoft may have addressed some of the
> > issues affecting XML's packaging ability. Dick Brooks accepted an
> > action item to contact Microsoft to request information describing
> > BizTalk's packaging functions to see if this may provide an XML
> > packaging solution that meets the above requirements.
> > </db>
> >
> > Another consideration in our work, and something clearly called out
> > in the ebXML requirements document are the vision bullets. Specifically:
> >     - is fully compliant with W3C XML technical specifications holding a
> >         recommended status
> >     - maximizes interoperability and efficiency while providing a
> >         transition path from accredited electronic data
> interchange (EDI)
> >         and developing XML business standards
> >
> > The first is key. It refers to W3C technical specifications holding
> > a *recommended* status. The second is also key. It refers to
> > a requirement to enable existing solutions such as RosettaNet and
> > EDI/INT, etc. to interoperate (at least that's how I read it).
> > This second bullet is called out again in the "General ebXML
> > Principles" section in the Requirements document. Someone certainly
> > thinks it s important. I for one concur.
> >
> > Another consideration which went into our thinking is the availability
> > of software to handle the package. HTTP and SMTP clients and
> > servers already support MIME and are both inexpensive and
> > widely available if not ubiquitous.
> >
> > In the Requirements document, under the TR&P sub-section, #2
> >     "Leveraging existing technology encompasses both the ability to
> >     interoperate with existing technology as well as the ability to
> >     migrate to the new technology".
> >
> > In fact, that whole section pretty much sums it up for me.
> >
> > I believe that there is consensus that ultimately, we will transition
> > to an XML-based approach to packaging, but at least for the
> > first go, MIME is the only solution which satisfies all of the
> > requirements.
> >
> > To my knowledge, the ebXML Requirements document doesn't
> > say "use XML to the exclusion of any other technology just because".
> > MIME seems to meet our requirements and since the content
> > of the MIME segments is XML (except in cases where an
> > "attachment" is of some other type such as image, etc.) we're
> > also meeting the spirit of the ebXML requirements.
> >
> > If you have knowledge of a purely XML-based packaging
> > solution which meets all of the stated requirements, and which
> > the packaging sub team has missed in its considerations, I'm
> > sure that we'd be glad to reconsider.
> >
> > Cheers,
> >
> > Chris
> >
> > "Kit (Christopher) Lueder" wrote:
> >
> > > I have a concern with the basic ebXML TRP approach. As I
> indicated last
> > > month, as far as I know, the TRP approach is in conflict with
> the ebXML
> > > Requirements specification. If I understand right, the ebXML TRP
> > > solution is MIME based only, which is not an XML solution.
> > >
> > > I quote the last paragraph from Section 1 Introduction of the ebXML
> > > Requirements:
> > > "A key aspect for the success of the ebXML initiative is adherence to
> > > the use of the W3C suite of XML and related Web technical
> > > specifications.  Although these specifications may not provide the
> > > optimal technical solution, acceptance of ebXML by the business
> > > community and technical community is tied to XML.  Alternative
> > > technologies and technical specifications may be incorporated
> as part of
> > > the ebXML solution.  However these alternative technologies and
> > > specifications will only be provided as an alternative to the provided
> > > XML solution unless the W3C XML and related Web technical
> specifications
> > > can not accomplish the same business functionality."
> > >
> > > Kit.
> > >
> > > Todd Boyle wrote:
> > > >
> > > > I would appreciate any information or links regarding the duplicated
> > > > or overlapping information in multiple layers of headers
> and wrappers.
> > > > My understanding is that a typical ebXML message might contain
> > > >
> > > >   HTTP/MIME multipart/related header
> > > >     ebXML header
> > > >     payload1
> > > >       Biztalk, or MSMQ/MQseries etc. header
> > > >       Biztalk, or MSMQ/MQseries etc. header
> > > >          Rosetta, OAG, CBL2, etc. document
> > > >              Rosetta, OAG, CBL2, etc. required document header
> > > >                  The XML message content which would usu. include
> > > >                  all the parties' identities and reference codes
> > > >     payload2
> > > >     payload3   etc.
> ...
>
> --
>     _/    _/             Kit C. J. Lueder
>    _/   _/         _/   The MITRE Corp.         Tel:  703-883-5205
>   _/_/_/    _/  _/_/_/ 1820 Dolley Madison Bl  Cell: 703-577-2463
>  _/   _/   _/    _/   Mailstop W722           FAX:  703-883-7996
> _/    _/  _/    _/   McLean, VA 22102        Mail: kit@mitre.org
> Worse than an unanswered question is an unquestioned answer.
>