RE: XML/EDI Reading

["Ajay K. Sanghi" <sanghi@xxxxxxxxxxxxxxxxxxxx>]

Ken,

In OO world, it's a good design and programming practice to keep your views (presentation) separate from document (that which holds data for processing).
This will help in adding more type of presentations to your existing data if need be. 

 If we see XML as a way of "standardized" presentation for our EDI data, then suddenly XML starts making sense, because now all that is required for the end-user is to have a Browser. The DTD (document type definition)  is already defined for what is to be presented and how. Customization for individual end user becomes simple by making changes either in the dtd (i hope not) or by way of attributes send in the XML data.

I agree with you that the size of the EDI data in XML form would enlarge (can even be more than twice the size of EDI data) which slows it down a bit but then you can have niche application which are not that voluminous in EDI data content and hence may be suitable for XML/EDI AND Browser viewing/submission. Of course if you are  connected to your ISP through a 14.4  kbps modem as I am then probably this would be your concern.

If you read the XML/EDI documents, you will find that it suggests an XML interface for "mappers". I'll request Bruce to please ellaborate on that since my understanding and vision on that may be limited for just producing XML data files from EDI files and/or flat files and viceversa.

In a nutshell, XML does make your data voluminous but it does not add complexity to your exisiting process. In fact is makes it simpler because now you not only have structured EDI data but also structured XML/EDI presentation data for it. Also, your existing EDI product becomes web-enabled almost "trivially".

If you are by any chance thinking that producing XML data from EDI data or flat-file would be complex then you are mistaken. Any decently good mapper would be able to handle this very-very easily.

Bruce, please help me for further questions that I am sure Ken would have. Also, please treat this as my initial comments for the XML-EDI mailing list as requested in your e-mail.

Regards,

ajay

----------
From: 	Ken Steel[SMTP:ksteel@xxxxxxxxxxx]
Sent: 	Sunday, August 10, 1997 8:34 AM
To: 	EDI-L@xxxxxxxxxxxxxxx
Subject: 	Re: XML/EDI Reading

Peat wrote:

> I agree that defining the categories is the place to start.

Why? Please give some reasons to support that statement.


> I don't think, the EDI-L mailing list is the place to perform a
> structured comparison of methodologies. Quite frankly, I don't think
> the task can be done properly here.

Why? Some substantiation and explanation would be useful.



>In a nutshell,
>XML/EDI incorporates the best of trad-EDI, the concept of a dynamic
>language of BSI, supports the mechanics of passed and externally
>defined objects (oo-edi), and utilizes the XML (baby brother to SGML)
>standard allowing for Internet and document-centric tools to be used.
> XML/EDI is in essence a superset of the other methodologies which
>Rik would like compare.

I would challenge that. XML can be used in all of them if one
is prepared to go the long way around to achieveing a goal, but
a superset it certainly isn't.

>XML is simply a tagging method which can be used to replace the
segment structure of trad-edi and the specification files of BSI,
but a very long-winded, clumsy and voluminous way of doing it. In
both areas it represents a significant increase in complexity
with highly dubious advantages in trad-edi and with significant
disadvantage for BSI.0

XML in no way encompasses the concepts of either trad-edi or
BSI so could not be considered in any way a superset.


As for applying it to Object Technology - show us how. Methinks
someone doesn't understand object technology with that wild
and unsubstantiated claim.


--
Ken Steel
The University of Melbourne
Department of Computer Science
ksteel@xxxxxxxxxxx
http://www.cs.mu.oz.au/research/icaris