Re: Party XML Schema Defintions

[Martin Bryan <mtbryan@sgml.u-net.com>]

Duane

> > Information
> > that is instance specific should remain a part of the message. If as a
part
> > of message validation you want to check that the message contents match
the
> > CPP contents then you do a match, using XSLT,

> Please be careful here.  Use of XSLT is not a requirement for ebXML nor
> would it likely be the preferred methodology for conducting XML to XML
> transforms.

Here is the only place I take issue with you. The original goal of the
XML/EDI initiative that preceded ebXML was to work out a way of introducing
EDI techniques to the 96% of businesses that do not have IT departments. It
was noted that a large percentage of these businesses had web browsers, that
the next generation of web browsers would use XML and would provide access
to XSLT transformation tools that could convert data into forms that could
be understood by the databases, spreadsheets, etc, the businesses already
had as part of the office suite used to run the business. A basic premise
was that SMEs would not be willing to buy specialist tools for handling
business messages - they would want to handle them using tools provided as a
standard part of the office suite.

One of my major criticisms of the ebXML initiative is that it has ignored
the goals for which the XML/EDI community was set up. It seems to presume
that all companies using ebXML will have IT departments, will have budgets
that will allow the purchasing of specialist ebMXL tools, and will have
in-house staff with time to fully understand the processes involved. This is
just rubbish. What the majority of  businesses need to do is to be able to
obtain from their trade body or local chamber of commerce some mechanism for
converting XML messages they receive to a form that their office suite
database or spreadsheet can understand, and some mechanism for generating
XML messages from these tools. The rules need to be easily transmittable,
easily extensible and sharable by people working with different office
suites. Given the volumes of business handled by most SMEs they do not need
to be super-efficient in operation. (Anyone with high enough volumes of
business can afford to hire IT specialists who can develop more efficient
processes suited to their business, or can afford to buy tools designed to
improve business efficiency which are out of the budget range of SMEs.)

The only language that I know that meets these requirements is XSLT. It is
easily transmittable in a form that allows the program to be checked (rather
than as a precompiled program that you have to be sure of your sources for),
it can be edited without the need for specialist tools using most office
suites, and can be handled using tools that are freely available in all
office suites. What alternative do you propose that offers the same
functionality (and please don't use a four letter word beginning with J).

Martin Bryan