Dear all
Here's my five bob's worth based on experience with EDI over many years
and the odd country or two....
If as is suggested we embark upon the "trading partnership arrangements"
model to determine TP specific software arguments or definitions, we
will re-invoke a level of complexity to the process which is horrible.
Having used many of the traditional VANs for EDI, the TP issues -
message types/versions/which decode programs to call etc... become an
administrative nightmare which precludes most people from using a
service as/when thay want to, eg NOW!
I am the Service Development Manager for Tradegate ECA which is the
Australian agency for UN EDIFACT as well as supporting general EDI
standards in Australian trade and transport through its association with
industry groups both regulatory - eg Cutsoms - and commercial. We also
run web form based bureau services based on UN EDIFACT standards which
are designed for SMEs who do not have ERP systems.
My own view - not necessarily that of Tradegate - is that any EDI
solutions should be 'promiscuous' (don't quote me) so that - using the
example of ASP web-based applications/XML, anyone can register for a
service and start using it straight away based upon a minimum
(assumed/default) requirement which is pre-defined by that service. In
commercial terms the client has signed up BUT as appropriate, behind the
vanilla flavoured registration (the promiscuous bit) are other features
which can include all sorts of security related stuff specifying
VPNs/encryption/electronic signatures and soforth. Such 'added' services
will be up to each EC service provider to determine and market according
to their relevance/benefits.
The point being that what we don't want to do is to leave a potential
service user at the mercy of his IT department or a registration process
which is overly complex. Otherwise the moment of inspiration might well
pass....
I think the above implies that similar to the current UN EDIFACT
processes, there will need to be a repository of valid DTDs just as
EDIFACT messages/directories are maintained and updated twice yearly.
For the purposes of THIS argument, such a process might be as simple as
ensuring that the DTD names are unique. I am not necessarily suggesting
that all DTDs have to be controlled - albeit I do believe that for
international cross-industry application they will have to be - but
stating the obvious, DTDs used in the public domain will have to be
unique otherwise users might well invoke the wrong one...
The answer seems to be a registry for DTDs in the public domain.
but have the ability to
ashwani madan wrote:
>
> >From: [EMAIL PROTECTED]
> >To: [EMAIL PROTECTED]
> >Subject: More than one root element in a DTD?
> >Date: Tue, 8 Aug 2000 11:14:57 -0400
> >
> >
> >
> >
> >Within the context of electronic commerce, is there ever more than
> >one root element in a DTD? If so, what is the practical use/meaning
> >of this?
>
> There is always one root element
>
> >Again in the context of electronic commerce, if the DTD name for an
> >XML document is an absolute URL, do users want a validating parser
> >to go out to the web and retrieve the DTD each time a document refers
>
> >to it? Isn't this an intolerable amount of overhead?
>
> Not necessary to always go to the web and validated against the DTD
> kept on the web.You can download the particular DTD on to the local
> host and validate against that.But before validation occurs from the
> local host , a small query might go to the particular web site to
> check if the DTD has been revised or not.If u have an old version
> downloaded then a message will pop-up on the screen asking if u want
> to download the updated version.Like it happens with "Internet
> Explorer" and "Netscape Navigator" whenever there is an update or a
> new plugin available a messsage is flashed on the screen to download
> it or not.I've found it most often with "messenger services" like MSN
> and yahoo.
>
> Ofcourse it has to be a part of the "architecture" at both the
> ends,the person who maintains the DTD and the person who uses the DTD.
>
> >Also, from a validation perspective, it seems common to specify the
> >DTD name using a relative path in the DOCTYPE element. What
> >is commonly done to prevent two different trading partners from
> >sending two different documents based on two different DTDs but both
> >the DTD's are named "po.dtd?"
>
> The common solution will be to use absolute paths,but even this is not
> necessary.Before two trading partners start an exchange it should be a
> part of "trading partner configuration" to know the details of his
> relative path. i.e., to know what is "po.dtd" relative to?
>
> >David Hixon
> >IBM Global Services
> >Tampa, FL USA
> >8-536-7382, (813) 801-7382
> >[EMAIL PROTECTED]
> >
> >
> >
> >
> >------ XML/edi Group Discussion List ------
> >Homepage = http://www.XMLedi-Group.org
> >
> >Unsubscribe = send email to: [EMAIL PROTECTED]
> >Leave the subject and body of the message blank
> >
> >Questions/requests: [EMAIL PROTECTED]
> >
> >To receive only one message per day (digest format)
> >send the following message to [EMAIL PROTECTED],
> >(leave the subject line blank)
> >
> >digest xmledi-group your-email-address
> >
> >To join the XML/edi Group complete the form located at:
> >http://www.xmledi-group.org/xmledigroup/mail1.htm
> >
> >
>
> ----------------------------------------------------------------------
> Get Your Private, Free E-mail from MSN Hotmail at
> http://www.hotmail.com
>
> ------ XML/edi Group Discussion List ------
> Homepage = http://www.XMLedi-Group.org
>
> Unsubscribe = send email to: [EMAIL PROTECTED]
> Leave the subject and body of the message blank
>
> Questions/requests: [EMAIL PROTECTED]
>
> To receive only one message per day (digest format)
> send the following message to [EMAIL PROTECTED],
> (leave the subject line blank)
>
> digest xmledi-group your-email-address
>
> To join the XML/edi Group complete the form located at:
> http://www.xmledi-group.org/xmledigroup/mail1.htm
------ XML/edi Group Discussion List ------
Homepage = http://www.XMLedi-Group.org
Unsubscribe = send email to: [EMAIL PROTECTED]
Leave the subject and body of the message blank
Questions/requests: [EMAIL PROTECTED]
To receive only one message per day (digest format)
send the following message to [EMAIL PROTECTED],
(leave the subject line blank)
digest xmledi-group your-email-address
To join the XML/edi Group complete the form located at:
http://www.xmledi-group.org/xmledigroup/mail1.htm
