Re: Brave new world

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

William

>The missing parts of an EDI guideline can
> be filled in from the base X12 or EDIFACT standard dictionaries, so
> there's no need to carry all that bulk in the igML message.  This, of
> course, means that a simple XSLT script would not be able to directly
> render the igML message as an understandable and readable EDI
> implementation guideline;  instead logic has to be applied to
> "recombine" the igML "delta" with a full EDI standard, whether in a
> database or in an igML file in it's own right.  Unfortunately, if what
> you say is true and XSLT can't even do a simple one-for-one matchup of
> code mnemonic to its description, then I would doubt it's suitable for
> the more complex logic of recombining guidelines with standards.
> Instead, our sample program demonstrates the process in C++ and the DOM.

What Arofan says is not true. Firstly you need to keep in mind that XSL works on the result of applying the DTD/Schema to the file, not on what the source file starts with, so any information the DTD adds to the elements is available to the XSLT processor. Secondly  you need to remember the XSLT processor can access and combine multiple resources. One that it will have to access in any case is the Schema. The more information that is available there the less external calls it will need to make elsewhere Arofan's concern is speed: as a programmer he thinks code in exchanged in scripts is more efficient than declarations of requirements specified in messages. Code may be more efficient in some cases, but without a standardized way of exchanging and referencing scripts we cannot guarantee its use within all systems. We can guarantee that an ebXML system will understand XML, and we can reasonably expect native XML tools to be fast at combining XML trees. We can guarantee that the Schema will be in memory (probably in an efficiently compiled format). Therefore we can guarantee that any ebXML tool can provide any information that is part of the Schema to any application that requires it. 

> In many cases, a re-engineering of the process will actually result in
> *SMALLER* XML documents than the files they replace!  By using the
> "delta" approach in building igML guidelines for all objects (not just
> text, as we had done before), our igML exports from the EDISIM product
> are significantly *SMALLER*, and *FASTER* to process than the equivalent
> SEF (Standards Exchange Format) files.  In this context, the size of the
> XML element tags is almost irrelevant.

This is the key: let the DTD/Schema and/or the XSLT do the work on receipt, and minimalize the transmitted message as far as is possible.

MArtin