VroniPlag Wiki

Angaben zur Quelle [Bearbeiten]

Autor     Pontus Norman
Titel    a study of eXtensible Markup Language (XML)
Datum    25. February 1999
Anmerkung    "This thesis is a part of the requirements for my (Pontus Norman’s) Master of Science degree in Computer Science at the Department of Teleinformatics, Royal Institute of Technology in Sweden." (p. 6)
URL    https://pdfs.semanticscholar.org/daae/6251759fc247ca60e4adf8598012c68df93f.pdf ; https://web.archive.org/web/20200225140015/https://pdfs.semanticscholar.org/daae/6251759fc247ca60e4adf8598012c68df93f.pdf

Literaturverz.   

no
Fußnoten    no
Fragmente    16


Fragmente der Quelle:
[1.] Svr/Fragment 002 11 - Diskussion
Zuletzt bearbeitet: 2020-03-16 15:44:17 [[Benutzer:|]]
Fragment, Gesichtet, KomplettPlagiat, Norman 1999, SMWFragment, Schutzlevel sysop, Svr

Typus
KomplettPlagiat
Bearbeiter
Schumann
Gesichtet
Yes.png
Untersuchte Arbeit:
Seite: 2, Zeilen: 11-12, 13-15
Quelle: Norman 1999
Seite(n): 44, Zeilen: 15 ff.
The idea behind EDI is a good one, unfortunately it has not worked out so well in reality. [After almost 30 years, only 2% - 5% of the companies today in Europe and the US make use of EDI (Segev et al. 1997).] One of the major problems with the current implementations of EDI is that they often require a unique solution for each pair of trading partners, making EDI costly and time-consuming to implement.

[Segev, A., Porra, J., & Roldan, M. 1997, Internet-Based EDI Strategy, working paper 97-WP-1021, [Online]. Available: http://haas.berkeley.edu/~citm/wp-1021.pdf
Accessed: 15 May 1999.]

The idea behind EDI is a good one, unfortunately it hasn’t worked out so well in reality. One of the major problems with the current implementations of EDI is that they often require a unique solution for each pair of trading partners, making EDI costly and time-consuming to implement.
Anmerkungen

The actual source is not given.

Segev et al. (1997) does not contain that content.

Sichter
(Schumann), WiseWoman


[2.] Svr/Fragment 027 22 - Diskussion
Zuletzt bearbeitet: 2020-03-16 15:53:06 [[Benutzer:|]]
Fragment, Gesichtet, Norman 1999, SMWFragment, Schutzlevel sysop, Svr, Verschleierung

Typus
Verschleierung
Bearbeiter
Schumann
Gesichtet
Yes.png
Untersuchte Arbeit:
Seite: 27, Zeilen: 22-26
Quelle: Norman 1999
Seite(n): 49, Zeilen: 1 ff.
Enterprise resource planning (ERP) software producers such as PeopleSoft Inc., Oracle Corp., and SAP AG already incorporate XML syntax into products to help companies lower the cost and labor involved in exchanging data with business partners. Third-party software vendors are pushing XML to enable data exchange over the Web between separate financial systems. Enterprise resource planning (ERP) heavyweights such as PeopleSoft Inc., Oracle Corp., and SAP AG plan to incorporate XML syntax into products to help companies lower the cost and labor involved in exchanging data with business partners. Separately, third-party software vendors are pushing XML to enable data exchange over the Web between separate financial systems.
Anmerkungen

The source is not given.

Sichter
(Schumann), WiseWoman


[3.] Svr/Fragment 029 22 - Diskussion
Zuletzt bearbeitet: 2020-03-16 15:57:46 [[Benutzer:|]]
Fragment, Gesichtet, KomplettPlagiat, Norman 1999, SMWFragment, Schutzlevel sysop, Svr

Typus
KomplettPlagiat
Bearbeiter
Schumann
Gesichtet
Yes.png
Untersuchte Arbeit:
Seite: 29, Zeilen: 22-27
Quelle: Norman 1999
Seite(n): 49, Zeilen: 7 ff.
- Web Interface Definition Language (WIDL), introduced in 1996, was one of the first applications of XML. WIDL provides a means of describing automated access to Web-enabled resources and enterprise applications through well-defined interfaces much like COM and CORBA. By abstracting information about Web and external application resources, applications can be protected from changes in the structure, appearance, and location of data. At the heart of webMethods B2B is the Web Interface Definition Language (WIDL) [11]. Introduced in 1996, WIDL was one of the first applications of XML. WIDL provides a means of describing automated access to Web-enabled resources and enterprise applications through well-defined interfaces much like COM and CORBA. By abstracting information about Web and external application resources, applications can be protected from changes in the structure, appearance, and location of data.

[11] Web Interface Definition Language (WIDL)
World Wide Web Consortium Note 22-September-1997
http://www.w3.org/TR/NOTE-widl-970922

Anmerkungen

The source is not given.

Sichter
(Schumann), WiseWoman


[4.] Svr/Fragment 032 13 - Diskussion
Zuletzt bearbeitet: 2020-03-18 15:49:25 [[Benutzer:|]]
Fragment, Gesichtet, Norman 1999, SMWFragment, Schutzlevel sysop, Svr, Verschleierung

Typus
Verschleierung
Bearbeiter
Schumann
Gesichtet
Yes.png
Untersuchte Arbeit:
Seite: 32, Zeilen: 13-20
Quelle: Norman 1999
Seite(n): 43, 44, Zeilen: 43: last paragraph; 44: 1 f.
[3. EDI]

Companies today have put great effort into constructing computer applications to help them in their business processes. While this has resulted in significant improvements in efficiency, that efficiency has not been extended to external processes. External processes are processes that involve interchange between applications or business processes at different companies. Companies have in many cases created islands of automation that are isolated from their suppliers, trading partners, and customers. EDI has been heralded as the solution to this problem.

3.4 XML and Electronic Transactions

Companies have today put great effort into constructing computer applications to help them in their business processes. While this has resulted in significant improvements in efficiency, that efficiency has not been extended to external processes. By external processes I mean processes that involve interchange between applications or business processes at different companies. Companies have in many cases created islands of automation that are isolated from their suppliers, trading partners, and customers. Electronic Data

[page 44]

Interchange (EDI) has been heralded as the solution to this problem.

Anmerkungen

The source is not given.

Sichter
(Schumann), WiseWoman


[5.] Svr/Fragment 042 07 - Diskussion
Zuletzt bearbeitet: 2020-03-17 21:34:05 [[Benutzer:|]]
Fragment, Gesichtet, KomplettPlagiat, Norman 1999, SMWFragment, Schutzlevel sysop, Svr

Typus
KomplettPlagiat
Bearbeiter
Schumann
Gesichtet
Yes.png
Untersuchte Arbeit:
Seite: 42, Zeilen: 7-9, 20-30
Quelle: Norman 1999
Seite(n): 44, Zeilen: 15 ff.
[3.3. Barriers for EDI penetration]

One of the major problems with the current implementations of EDI is that they often require a unique solution for each pair of trading partners, making EDI costly and time-consuming to implement. [...]

[3.3.1 Limited number of standard EDI documents defined]

[...]

Another problem with traditional EDI is that it is based on the use of rigid transaction sets with business rules embedded in them. These transaction sets are defined by standards bodies such as the United Nations Standards Messages Directory for Electronic Data Interchange for Administration, Commerce, and Transport (UN/EDIFACT) and American National Standards Institute’s Accredited Standards Committee X12 sub-group (ANSI X12). Transaction sets define the fields, the order of these fields, and the length of the fields. Along with these transactions sets there are business rules, which in EDI-language are referred to as implementation guidelines (United Nations 1999 and ASC12 1999).

A fixed transaction set prevents companies from evolving by adding new services and products or changing business processes. The bodies that make the standard [transaction sets are ill equipped to keep up with the rapid pace of change in the various business environments they impact.]


ASC12 (eds). 1996, Data International Standards Association (DISA), [Online]. Available: http://polaris.disa.org/
Accessed 15 May 1999.

United Nations, Rules for Electronic Data Interchange for Administration, Commerce, and Transport (EDIFACT), [Online]. Available: http://www.unece.org/trade/untdid/welcom1.htm
Accessed: 14 May 1999.

One of the major problems with the current implementations of EDI is that they often require a unique solution for each pair of trading partners, making EDI costly and time-consuming to implement.

Another problem with traditional EDI is that it is based on the use of rigid transaction sets with business rules embedded in them. These transaction sets are defined by standards bodies such as the United Nations Standards Messages Directory for Electronic Data Interchange for Administration, Commerce, and Transport (UN/EDIFACT) [30] and American National Standards Institute’s Accredited Standards Committee X12 sub-group (ANSI X12) [32]. Transaction sets define the fields, the order of these fields, and the length of the fields. Along with these transactions sets are business rules, which in EDI-language are referred to as “implementation guidelines”.

[...]

A fixed transaction set prevents companies from evolving by adding new services and products or changing business processes. The bodies that make the standard transaction sets are ill equipped to keep up with the rapid pace of change in the various business environments they impact.


[30] Rules for Electronic Data Interchange for Administration, Commerce, and Transport (EDIFACT)
United Nations
http://www.unece.org/trade/untdid/welcom1.htm

[32] Data International Standards Association (DISA)
Accredited Standards Committee X12 (ASC12)
http://polaris.disa.org/

Anmerkungen

The actual source is not given.

Sichter
(Schumann), WiseWoman


[6.] Svr/Fragment 043 01 - Diskussion
Zuletzt bearbeitet: 2020-03-17 21:36:56 [[Benutzer:|]]
Fragment, Gesichtet, KomplettPlagiat, Norman 1999, SMWFragment, Schutzlevel sysop, Svr

Typus
KomplettPlagiat
Bearbeiter
Schumann
Gesichtet
Yes.png
Untersuchte Arbeit:
Seite: 43, Zeilen: 1-3
Quelle: Norman 1999
Seite(n): 44, Zeilen: 30 ff.
[The bodies that make the standard] transaction sets are ill equipped to keep up with the rapid pace of change in the various business environments they impact. It is also very hard, if not impossible, to develop a one-size-fits-all solution. The bodies that make the standard transaction sets are ill equipped to keep up with the rapid pace of change in the various business environments they impact. It is also very hard, if not impossible, to develop a one-size-fits-all solution.
Anmerkungen

Continued from previous page.

The source ist not given.

Sichter
(Schumann), WiseWoman


[7.] Svr/Fragment 046 16 - Diskussion
Zuletzt bearbeitet: 2020-03-17 21:44:56 [[Benutzer:|]]
Fragment, Gesichtet, KomplettPlagiat, Norman 1999, SMWFragment, Schutzlevel sysop, Svr

Typus
KomplettPlagiat
Bearbeiter
Schumann
Gesichtet
Yes.png
Untersuchte Arbeit:
Seite: 46, Zeilen: 16-17, 23-32
Quelle: Norman 1999
Seite(n): 44, 45, Zeilen: 44: last paragraph; 45: 26 ff.
[3.4.3 XML/EDI]

By using XML to implement EDI many of the old problems of EDI (as discussed in previous chapter) are eliminated. [...] XML therefore maintains the content and structure, but separates the business rules from the data. By focusing on exchanging data content and structure, trading partners can apply their own business rules. Using XML it is also very easy to extend the communication to support new business processes, EDI will no longer be limited to rigid standards.

The fact that XML documents can easily be distributed using the Internet is another major advantage. This combined with the fact that XML is self-explaining provides the entire framework for what the XML/EDI group calls a new supply web. Earlier many EDI implementations only worked within their own Intranets. With XML this is no longer the case since XML provides connectivity through the [Internet.]

3.4.2 EDI using XML

By using XML to implement EDI many of the old problems are eliminated. XML maintains the content and structure, but separates the business rules from the data. By focusing on exchanging data content and structure, trading partners can apply their own business rules. Using XML it is also very easy to extend the communication to support new business processes, EDI will no longer be limited to rigid standards.

[page 45]

The fact that XML documents can easily be distributed using the Internet is another major advantage. This combined with the fact that XML is self-explaining provides the entire framework for what the XML/EDI group calls a new “supply web”. Earlier many EDI implementations only worked within their own Intranets. With XML this is no longer the case since XML provides connectivity through the Internet.

Anmerkungen

The source is not given.

Sichter
(Schumann), WiseWoman


[8.] Svr/Fragment 047 01 - Diskussion
Zuletzt bearbeitet: 2020-03-17 22:10:53 [[Benutzer:|]]
Fragment, Gesichtet, KomplettPlagiat, Norman 1999, SMWFragment, Schutzlevel sysop, Svr

Typus
KomplettPlagiat
Bearbeiter
Schumann
Gesichtet
Yes.png
Untersuchte Arbeit:
Seite: 47, Zeilen: 1-4
Quelle: Norman 1999
Seite(n): 45, Zeilen: 29 ff.
All applications are then able to communicate and exchange data, thus the old point-to-point solutions are history. To many people XML/EDI is also what they call a politically correct way to merge ANSI X12 (the US standard) and EDIFACT (the international standard). All applications are then able to communicate and exchange data, thus the old point-to-point solutions are history. To many people XML-EDI is also what they call a ‘politically correct’ way to merge ANSI X12 (the US standard) and EDIFACT (the world standard).
Anmerkungen

Continued from the previous page.

The source is not given.

Sichter
(Schumann), WiseWoman


[9.] Svr/Fragment 050 19 - Diskussion
Zuletzt bearbeitet: 2020-03-18 20:41:07 [[Benutzer:|]]
Fragment, Gesichtet, Norman 1999, SMWFragment, Schutzlevel sysop, Svr, Verschleierung

Typus
Verschleierung
Bearbeiter
Schumann
Gesichtet
Yes.png
Untersuchte Arbeit:
Seite: 50, Zeilen: 19-20
Quelle: Norman 1999
Seite(n): 44, Zeilen: 11 ff.
Using EDI, it is not necessary for the trading partners to have identical document processing systems. When the [sender sends a document, EDI translation software can convert the proprietary format into an agreed upon standard.] When you use EDI, it's not necessary for the trading partners to have identical document processing systems. When the sender sends a document, EDI translation software can convert the proprietary format into an agreed upon standard.
Anmerkungen

The source is not given.

Sichter
(Schumann), WiseWoman


[10.] Svr/Fragment 051 01 - Diskussion
Zuletzt bearbeitet: 2020-05-21 21:15:16 [[Benutzer:|]]
Fragment, Gesichtet, KomplettPlagiat, Norman 1999, SMWFragment, Schutzlevel sysop, Svr

Typus
KomplettPlagiat
Bearbeiter
Schumann
Gesichtet
Yes.png
Untersuchte Arbeit:
Seite: 51, Zeilen: 1-4
Quelle: Norman 1999
Seite(n): 44, Zeilen: 12 ff.
[When the] sender sends a document, EDI translation software can convert the proprietary format into an agreed upon standard. When the receiver receives the document, his EDI translation software automatically changes the standard format into the proprietary format of his document processing software. When the sender sends a document, EDI translation software can convert the proprietary format into an agreed upon standard. When the receiver receives the document, his EDI translation software automatically changes the standard format into the proprietary format of his document processing software.
Anmerkungen

The source is not given.

Sichter
(Schumann), WiseWoman


[11.] Svr/Fragment 056 02 - Diskussion
Zuletzt bearbeitet: 2020-03-18 20:56:52 [[Benutzer:|]]
Fragment, Gesichtet, KomplettPlagiat, Norman 1999, SMWFragment, Schutzlevel sysop, Svr

Typus
KomplettPlagiat
Bearbeiter
Schumann
Gesichtet
Yes.png
Untersuchte Arbeit:
Seite: 56, Zeilen: 2-26
Quelle: Norman 1999
Seite(n): 45, Zeilen: 6 ff.
[4.2.1 Impact of XML on EDI]

What XML provides is primarily (a) Self-explaining syntax, (b) Modularity, (c) Extensibility, (d) Presentation, and (e) Transformation.

Self-explaining syntax: Since the elements in XML are discoverable using document type definitions, the elements used to describe a supplier's product, its pricing, or other attributes can be gleaned without first having to agree upon a single format beforehand. Previous visions of EDI could not use this kind of ad hoc partnership approach. At best, an industry might define a set of EDI templates or forms for specific transaction types. Generally, these would be established by the largest company in a supply chain as a de facto set of transaction standards and data types.

Modularity: The XML/EDI messages can be constructed using a combination of several standardized modules. It is possible to provide a number of standardized and publicly accepted building blocks that can be used to construct more complex EDI messages. This is quite different from the current implementations where all the functionally has to be included in the messages from the beginning, resulting in that people are adding all kinds of messages in the standards because they may be used in the future.

Extensibility: Since the EDI standard using XML is no longer under the eye of standardization committees, such as UN/EDIFACT and ANSI X12, it is much easier to add new support and functionality in the EDI messages.

Presentation: The XML/EDI messages can be presented directly to the user using the XSL specification (when and if such support becomes available in the browsers).

Transformation: The XML/EDI messages can be processed transformed and analyzed using the proposed XML/QL standardization.

What XML provides is primarily:

· Self-explaining syntax: Since the elements in XML are discoverable using document type definitions, the elements used to describe a supplier's product, its pricing, or other attributes can be gleaned without first having to agree upon a single format beforehand. Previous visions of EDI could not use this kind of ad hoc partnership approach. At best, an industry might define a set of EDI templates or forms for specific transaction types. Generally, these would be established by the largest company in a supply chain as a de facto set of transaction standards and datatypes.

· Modularity: The XML – EDI messages can be constructed using a combination of several standardized modules. It is possible to provide a number of standardized and publicly accepted building blocks that can be used to construct more complex EDI messages. This is quite different from the current implementations where all the functionally has to be included in the messages from the beginning, resulting in that people are adding all kinds of messages in the standards because they MAY be used in the future.

· Extendibility: Since the EDI standard using XML is no longer under the eye of standardization committees, such as UN/EDIFACT and ANSI X12, it is much easier to add new support and functionality in the EDI messages.

· Presentation: The XML – EDI messages can be presented directly to the user using the XSL specification (when and if such support becomes available in the browsers).

· Transformation: The XML – EDI messages can be processed, transformed and analyzed using the proposed XML-QL standardization.

Anmerkungen

The source is not given.

Sichter
(Schumann), WiseWoman


[12.] Svr/Fragment 060 07 - Diskussion
Zuletzt bearbeitet: 2020-03-18 21:15:35 [[Benutzer:|]]
Fragment, Gesichtet, KomplettPlagiat, Norman 1999, SMWFragment, Schutzlevel sysop, Svr

Typus
KomplettPlagiat
Bearbeiter
Schumann
Gesichtet
Yes.png
Untersuchte Arbeit:
Seite: 60, Zeilen: 7-19, 27-32
Quelle: Norman 1999
Seite(n): 44, 47, 48, Zeilen: 44: 7 ff.; 47: 2 ff.; 48: last paragraph
The XML/EDI groups are working to define XML namespaces and DTDs equal to the EDIFACT standard to support commercial usage of EDI over XML. Even though most organizations agree that EDI using XML is a good idea some are still skeptical. This is due to the fact that they think that EDI is too complex to be dealt with easily. In the health care industry alone, there are 400 different formats for a claim. One of the key issues will be how compatible the new implementations of EDI will be to the old ones; currently there is no answer to this question.

Furthermore a big debate is going on between the different XML/EDI groups on what the structure of the XML tags should be. Some advocate the use of the full description in the tag and others the use of the ANSI element number as the tag name. Others want to use a unique number that would include the standard version of the directory, the segment it resides in and the data-element it represents.

[...]

[4.4. XML/EDI Example]

EDI is quite different from sending electronic mail messages or sharing files through a network, a modem, or a bulletin board. The straight transfer of computer files requires that the computer applications of both the sender and receiver (referred to as "trading partners") agree upon the format of the document. The sender must use an application that creates a file format identical to the receiver’s computer application.

[page 48]

The XML/EDI group [1] is working to define XML namespaces and DTDs equal to the EDIFACT standard to support commercial usage of EDI over XML. Even though most organizations agree that EDI using XML is a good idea some are still skeptical. This is due to the fact that they think that EDI is too complex to be dealt with easily. In the health care industry alone, there are 400 different formats for a claim. One of the key issues will be how compatible the new implementations of EDI will be to the old ones; currently there is no answer to this question.

[page 47]

Currently a big debate is going on between the different XML-EDI groups on what the structure of the XML tags should be. Some advocate the use of the full description in the tag and others the use of the ANSI element number as the tag name. Others want to use a unique number that would include the standard version of the directory, the segment it resides in and the data-element it represents.

[page 44]

EDI is quite different from sending electronic mail messages or sharing files through a network, a modem, or a bulletin board. The straight transfer of computer files requires that the computer applications of both the sender and receiver (referred to as "trading partners") agree upon the format of the document. The sender must use an application that creates a file format identical to the receiver’s computer application.

Anmerkungen

The source is not given.

Sichter
(Schumann), WiseWoman


[13.] Svr/Fragment 061 01 - Diskussion
Zuletzt bearbeitet: 2020-03-20 23:20:29 [[Benutzer:|]]
Fragment, Gesichtet, Norman 1999, SMWFragment, Schutzlevel sysop, Svr, Verschleierung

Typus
Verschleierung
Bearbeiter
Schumann
Gesichtet
Yes.png
Untersuchte Arbeit:
Seite: 61, Zeilen: 1 ff. (completely)
Quelle: Norman 1999
Seite(n): 45, 46, Zeilen: 45: 38 ff.; 46: 1 ff.
A retailer stocks inventory from a major manufacturer. For years this retailer has been ordering merchandise from the manufacturer using a human-readable purchase order such as that in Figure 11 for 1000 fuzzy dice. Now fuzzy dice manufacturer is demanding that the retailer begin using EDI for transactions or surcharge will be added to every order to offset the cost of handling manual transactions. The small retailer can't find a more lenient supplier, so it has little choice.

Svr 061 diss.png

Figure 11: Plain purchase order

Unfortunately, EDI compliance means that the retailer will now have to transmit its purchase orders in a format specified in one of the several standard sets for EDI format, the most widely used being ANSI X12 and UN/EDIFACT. Figure 12 shows part of an ANSI X12 version of the purchase order in Figure 11.

ST*850*12345
BEG*00*SA*3429**981201
N1*BY*Internet Retailer Inc.*91*RET8999
N1*ST*Internet Retailer Inc.
N3*123 Via Way
N4*Milwaukee*WI*53202
PER*OC*John Johnson
PO1**100*EA*1.23*WE*MG*CO633
SE*9*12345

Figure 12: Fragment of ANSI X12 transaction set corresponding to Figure 11

It's possible that the retailer's current accounting software supports EDI transactions, but not likely. It will probably have to either convert to software that [does, purchase software that can make the translation (if available), or contract with a third party to convert the data on an ongoing basis.]

[page 45]

Consider a small, Web-based retailer that stocks inventory from a major manufacturer. For years the company has been ordering merchandise from the manufacturer using a human-readable purchase order such as that in Listing 1, for 1000 fuzzy dice. Now the manufacturer is demanding that the retailer begin using EDI for transactions or else it will add a surcharge to every order to offset the cost of handling manual transactions. The small retailer can’t find a more lenient supplier, so it has little choice.

Listing 1: Plain purchase order

Svr 061 source.png

[page 46]

Unfortunately, EDI compliance means the retailer will now have to transmit its purchase orders in a format specified in one of the several standard sets for EDI format, the most widely used being ANSI X12 and UN/EDIFACT. Listing 2 shows part of an ANSI X12 version of the purchase order in Listing 1. It’s possible that the retailer’s current accounting software supports EDI transactions, but not likely. It will probably have to either convert to software that does, purchase software that can make the translation (if available), or contract with a third party to convert the data on an ongoing basis.

Listing 2: Fragment of ANSI X12 transaction set corresponding to Listing 1

ST*850*12345
BEG*00*SA*3429**981201
N1*BY*Internet Retailer Inc.*91*RET8999
N1*ST*Internet Retailer Inc.
N3*123 Via Way
N4*Milwaukee*WI*53202
PER*OC*John Johnson
PO1**100*EA*1.23*WE*MG*CO633
SE*9*12345

Anmerkungen

The source is not given.

Sichter
(Schumann), SleepyHollow02


[14.] Svr/Fragment 062 01 - Diskussion
Zuletzt bearbeitet: 2020-03-20 23:22:45 [[Benutzer:|]]
Fragment, Gesichtet, KomplettPlagiat, Norman 1999, SMWFragment, Schutzlevel sysop, Svr

Typus
KomplettPlagiat
Bearbeiter
Schumann
Gesichtet
Yes.png
Untersuchte Arbeit:
Seite: 62, Zeilen: 1 ff. (completely)
Quelle: Norman 1999
Seite(n): 46, Zeilen: 3 ff.
[It's possible that the retailer's current accounting software supports EDI transactions, but not likely. It will probably have to either convert to software that] does, purchase software that can make the translation (if available), or contract with a third party to convert the data on an ongoing basis.

Svr 062a diss.png Svr 062b diss.png

Figure 13: XML document analogue to the X12 transaction set in Figure 12

Would there be any advantage, for the retailer or the manufacturer, to using an XML format instead? Perhaps the retailer's accounting software is tailored to [Internet commerce, and already uses XML formats.]

It’s possible that the retailer’s current accounting software supports EDI transactions, but not likely. It will probably have to either convert to software that does, purchase software that can make the translation (if available), or contract with a third party to convert the data on an ongoing basis.

[...]

So, would there be any advantage, for the retailer or the manufacturer, to using an XML format instead? Perhaps the retailer’s accounting software is tailored to Internet commerce, and already uses XML formats. [...]

Listing 3: XML document analog to the X12 transaction set in Listing 2

Svr 062 source.png

Anmerkungen

The source is not given.

Sichter
(Schumann), SleepyHollow02


[15.] Svr/Fragment 063 01 - Diskussion
Zuletzt bearbeitet: 2020-03-20 23:25:06 [[Benutzer:|]]
Fragment, Gesichtet, Norman 1999, SMWFragment, Schutzlevel sysop, Svr, Verschleierung

Typus
Verschleierung
Bearbeiter
Schumann
Gesichtet
Yes.png
Untersuchte Arbeit:
Seite: 63, Zeilen: 1 ff. (completely)
Quelle: Norman 1999
Seite(n): 46, 47, 48, Zeilen: 46: 18 ff.; 47: 28 ff.; 48: 1 ff., 8 ff., 14 f.
[Perhaps the retailer's accounting software is tailored to] Internet commerce, and already uses XML formats. In this case, there are utilities for converting one data type definition (DTD) to another, and a generic tool accomplishes the conversion to EDI. The resulting transmission would certainly be more comprehensible to humans, and perhaps even feasible for an employee with a text editor or XML editor to generate. An example of how the sample purchase order might look in an XML rendering of X12 is given in Figure 13. This example is based on the ongoing work of the XML/EDI group. One disadvantage with using XML, as can be seen below, is that the size of the EDI messages gets a lot bigger than the X12 messages. In this example, the XML message is about 8 times bigger than the X12 message.

The idea of XML repositories is to provide a means for industries to store the document-type definitions, that identify the data elements and their relationships exchanged among parties doing business electronically, on the Internet. Repositories contain logic components, such as Java applets, template scripts, forms and object definitions needed to process message components. With common registration procedures for these components, repositories will act as global libraries, and enable industry groups, government agencies, and businesses of all sizes to make their preferred message formats widely available to current and potential trading partners. The intent of the Global Repository is to be a dynamic mechanism that responds through an open Application Programming Interface (API). It is anticipated that fully functional global repositories will evolve in phases:

Phase 1 Limited Intranet implementation, proof of concept, with manual Web interface.

Phase 2 Definition of basic API allows extranet implementations between specific partners.

Phase 3 Definition of full API and available repository products allows full implementations.

Phase 4 DNS style service established and standards bodies adopt support for API and long-term maintenance and alignment.

[page 46]

Perhaps the retailer’s accounting software is tailored to Internet commerce, and already uses XML formats. In this case, there are utilities for converting one data type definition (DTD) to another, and the conversion to EDI might be accomplished by a generic tool. The resulting transmission would certainly be more comprehensible to humans, and perhaps even feasible for an employee with a text editor or XML editor to generate. An example of how the sample purchase order might look in an XML rendering of X12 is given in Listing 3. This example is based on the ongoing work of the XML/EDI group. One disadvantage with using XML, as can be seen below, is that the size of the EDI messages gets a lot bigger than the X12 messages. In this example, the XML message is about 8 times bigger than the X12 message.

[page 47]

XML repositories will provide a means for industries to store on the World Wide Web the document-type definitions that identify the data elements and their relationships exchanged among parties doing business electronically. Repositories will also contain logic components, such as Java applets, template scripts, forms and object definitions needed to process message components.

[page 48]

With common registration procedures for these components, repositories will act as global libraries, and enable industry groups, government agencies, and businesses of all sizes to make their preferred message formats widely available to current and potential trading partners.

[...]

It is anticipated that fully functional global repositories will evolve in phases:

· Phase 1 - Limited Intranet implementation, proof of concept, with manual Web interface.

· Phase 2 - Definition of basic API allows Extranet implementations between specific partners.

· Phase 3 - Definition of full API and available repository products allows full implementations.

· Phase 4 - DNS style service established and standards bodies adopt support for API and long term maintenance and alignment.

[...]

The intent of the Global Repository is to be a dynamic mechanism that responds through an open Application Programming Interface (API).

Anmerkungen

The source is not given.

Sichter
(Schumann), SleepyHollow02


[16.] Svr/Fragment 064 01 - Diskussion
Zuletzt bearbeitet: 2020-03-20 23:26:38 [[Benutzer:|]]
Fragment, Gesichtet, Norman 1999, SMWFragment, Schutzlevel sysop, Svr, Verschleierung

Typus
Verschleierung
Bearbeiter
Schumann
Gesichtet
Yes.png
Untersuchte Arbeit:
Seite: 64, Zeilen: 1-7
Quelle: Norman 1999
Seite(n): 48, Zeilen: 15 ff.
Svr 064 Diss.png

Figure 14: XML/EDI Transaction Schematics Example:

An XML-EDI transaction using a global repository

(1) The Retailer queries the Global Repository for the structure (DTD) of those common business objects that are to be passed to the trading partner, the manufacturer.

(2) The business objects are passed to the Manufacturer, using XML documents structured according to the DTDs fetched from the Global Repository.

(3) The Manufacturer maps the received data in to the organization’s application system. The mapping is received from the Global Repository.

Example: An XML-EDI transaction using a global repository

Svr 064 Source.png

Figure 11: XML/EDI Transaction Schematics

A user or agent in Organization 1 queries the Global Repository for the structure (DTD) of those common business objects that are to be passed to a trading partner - Organization 2.

· The business objects are passed to Organization 2, using XML documents structured according to the DTDs fetched from the Global Repository.

· The receiver maps the received data in to the organization’s application system. The mapping is received from the Global Repository.

Anmerkungen

The source is not given.

Sichter
(Schumann), SleepyHollow02