Angaben zur Quelle [Bearbeiten]
| Autor | Bruce Peat / David Webber |
| Titel | XML/EDI: The E-business Framework |
| Datum | August 1997 |
| URL | https://www.xmledi-group.org/start.html |
Literaturverz. |
yes |
| Fußnoten | yes |
| Fragmente | 6 |
| [1.] Svr/Fragment 049 13 - Diskussion Zuletzt bearbeitet: 2020-01-15 16:21:13 Klgn | Fragment, Gesichtet, Peat Webber 1997, SMWFragment, Schutzlevel sysop, Svr, Verschleierung |
|
|
|
| Untersuchte Arbeit: Seite: 49, Zeilen: 13-19 |
Quelle: Peat Webber 1997 Seite(n): online, Zeilen: 0 |
|---|---|
| By using the XML extensible tag set, EDI objects can be either passed or dynamically referenced [sic] to objects stored in repositories. The XML/EDI Group (see chapter 4.1.4. and Appendix) is proposing the use of XML as a carrier for the document information so that the transaction can carry not only data, but also code (at each level in the transaction tree). With an element having data properties and code methods, this allows the business elements to be manipulated as objects. | By using the XML extensible tag set, EDI "objects" can be either passed or dynamically reference to objects stored in repositories. The XML/EDI Group is proposing the use of XML as a "carrier" for the document information so that the transaction can carry not only data (like trad-edi), but also code (at each level in the transaction tree). With an element having data properties and code methods, this allows the business elements to be manipulated as "objects". |
No source is given. |
|
| [2.] Svr/Fragment 050 11 - Diskussion Zuletzt bearbeitet: 2020-04-16 20:53:34 WiseWoman | BauernOpfer, Fragment, Gesichtet, Peat Webber 1997, SMWFragment, Schutzlevel sysop, Svr |
|
|
|
| Untersuchte Arbeit: Seite: 50, Zeilen: 11-19 |
Quelle: Peat Webber 1997 Seite(n): online, Zeilen: 0 |
|---|---|
| [- XML (transport, metadata, parsing)
- EDI (business transactions) - Repositories (business process entities) - Templates (business rules & information exchange) - Agents (control and facilitation)]
XML itself provides the foundation. The Web was born on the abilities of the HTML language, itself a very limited subset of the original and highly complex SGML document syntax. Now XML has been created that sits between the two, not as complex as SGML, but vastly more capable than HTML. XML tokens and frameworks are the syntax that transports the other components across the network. XML tokens replace of [sic] supplement existing segment identifiers. XML also brings with it all the rich capabilities and transport layers of the Web and the Internet in general. EDI is the grandfather of the current e-commerce. Peat, B. & Webber, D. August 1997, XML/EDI: The E-business Framework, [Online]. Available: http://www.geocities.com/WallStreet/Floor/5815/startde.htm |
Each component adds unique tools that leverage the other pieces. In the past EDI was very static, today the XML/EDI framework provides is an exciting dynamic process that can be infinitely extended. We now look at each technology to give you an overview, while later sections provide more in depth looks at each.
Figure 1. XML/EDI the Fusion of Technologies The Power of Five: XML itself provides the foundation. The Web was born on the abilities of the HTML language, itself a very limited subset of the original and highly complex SGML document syntax. Now XML has been created that sits between the two, not as complex as SGML, but vastly more capable than HTML. XML tokens and frameworks are the syntax that transports the other components across the network. XML tokens replace or supplement existing EDI segment identifiers. XML also brings with it all the rich capabilities and transport layers of the Web and the Internet in general. EDI is the grandfather of the electronic commerce. |
The source is given, but no quotation marks are used. Figure 8 appears to be a copy from the source. |
|
| [3.] Svr/Fragment 051 21 - Diskussion Zuletzt bearbeitet: 2020-05-17 22:35:02 Schumann | BauernOpfer, Fragment, Gesichtet, Peat Webber 1997, SMWFragment, Schutzlevel sysop, Svr |
|
|
|
| Untersuchte Arbeit: Seite: 51, Zeilen: 21-28 |
Quelle: Peat Webber 1997 Seite(n): online, Zeilen: 0 |
|---|---|
| According to Peat and Webber (1999) XML/EDI provides four core models of use. These include traditional EDI deployment methods, along with new documentcentric capabilities. Figure 6 shows at a glance the four core models: (i) Star Model, (ii) Ad-hoc Model, (iii) Hybrid Model, and (iv) Web Model.
The Star-model shown is the classic EDI model, where a major business partner or organization sets the standards for its trading partners. The Ad-hoc-model is the new net-based model. Smaller trading partners setup their own ad hoc interactions, these in time may evolve into more formal methods, or they may not. Peat, B. & Webber, D. August 1997, XML/EDI: The E-business Framework, [Online]. Available: http://www.geocities.com/WallStreet/Floor/5815/startde.htm |
XML/EDI provides four core models of use. These include traditional EDI deployment methods, along with new document-centric capabilities. Figure 2 shows at a glance the four core models.
[...] The "star" model shown is the classic EDI model, where a major business partner or organization sets the standards for its trading partners. The "ad hoc" model is the new net-based model. Smaller trading partners setup their own ad hoc interactions, these in time may evolve into more formal methods, or they may not. |
The source is given but it is not made clear that the text is so extensively copied - no quotation marks. |
|
| [4.] Svr/Fragment 052 01 - Diskussion Zuletzt bearbeitet: 2020-01-19 22:34:17 Schumann | BauernOpfer, Fragment, Gesichtet, Peat Webber 1997, SMWFragment, Schutzlevel sysop, Svr |
|
|
|
| Untersuchte Arbeit: Seite: 52, Zeilen: 1 ff. (completely) |
Quelle: Peat Webber 1997 Seite(n): online, Zeilen: 0 |
|---|---|
| The Hybrid-model is a combination of the first two. Here a "Star" model is extended by trading partners, by creating new versions of frameworks, and by linking in their own ad hoc ones. The Web-model is a document-centric model, where content is the most important information being exchanged. Content can either arrive driven by pre-set rules, or be requested, or be broadcast. The classic example for this is an electronic catalog, and the associated Request for Quotations (RFQ) dialogs.
4.1.3 XML/EDI as a Framework XML/EDI provides for the infrastructure of a wide variety of e-commerce systems, from searchable on-line catalogs to robust machine-to-machine transaction subsystems. The XML/EDI initiative is to provide open solutions for implementing e-business systems today, as there is more than just one standard solution for all of the e-business scenarios. Each scenario has its own requirements and goals. Thus a framework and not an application or module is required. The goal of the framework is to provide formal interfaces for commercial e-commerce components to interoperate. For XML/EDI to be successful these interfaces will be open and yet standardized. The business model is either of ad hoc interactions between [small groups, or agreed upon national or international frameworks, such as those by trade associations or industry bodies (Peat and Webber, 1999).] Peat, B. & Webber, D. August 1997, XML/EDI: The E-business Framework, [Online]. Available: http://www.geocities.com/WallStreet/Floor/5815/startde.htm |
The "hybrid" model is a combination of the first two. Here a "Star" model is extended by trading partners, by creating new versions of frameworks, and by linking in their own ad hoc ones. The "Web" model is a document-centric model. Where content is the most important information being exchanged. Content can either arrive driven by pre-set rules, or be requested, or be broadcast. The classic example for this is an electronic catalog, and the associated "Request For Quotations" (RFQ) dialogs.
Why a framework? XML/EDI provides for the infrastructure of a wide variety of EC systems; from searchable on-line catalogs to robust machine-to-machine transaction subsystems. The XML/EDI initiative is to provide open solutions for implementing E-business systems today. The operative word here is "solutions". There isn't just one solution for all of the E-business scenarios. Each scenario has its own requirements and goals. This is why we need a framework and not an application or module. The goal of the framework is to provide formal interfaces for commercial EC components to interoperate. For XML/EDI to be successful these interfaces will be open and yet standardized. The business model is either of ad hoc interactions between small groups, or agreed upon national or international frameworks, such as those by trade associations or industry bodies. |
The source is given but it is not made clear that the text is so extensively copied - no quotation marks. |
|
| [5.] Svr/Fragment 053 01 - Diskussion Zuletzt bearbeitet: 2020-01-19 22:32:28 Schumann | BauernOpfer, Fragment, Gesichtet, Peat Webber 1997, SMWFragment, Schutzlevel sysop, Svr |
|
|
|
| Untersuchte Arbeit: Seite: 53, Zeilen: 1 ff. (completely) |
Quelle: Peat Webber 1997 Seite(n): online, Zeilen: 0 |
|---|---|
| [The business model is either of ad hoc interactions between] small groups, or agreed upon national or international frameworks, such as those by trade associations or industry bodies (Peat and Webber, 1999).
[Figure 10] Figure 10: XML/EDI Layered Architecture (Peat/Webber, 1999). Figure 10 depicts the technical layers that a base XML/EDI system can be built on. Not all layers are required to achieve results with XML/EDI. The framework builds upon and enhances the XML and EDI standards and defines the blueprint of ecommerce component interaction. For example, catalog vendors may only want to implement the XML tagging. The tags are defined in standard repositories. The various layers support different targeted e-commerce systems. Overall each successive layer provides increasingly more sophisticated capabilities so as to handle more demanding needs (Peat and Webber, 1999). The framework is not an all-or-nothing implementation. Each e-commerce component is designed to be able to be used independently, interfacing with each other as defined by XML/EDI standards. DTDs formally define the structure of EDI messages without having to use it to validate well-formed XML documents. EDIFACT/X12 messages can simply be placed in an XML shell element or the message (or parts of it) can be coded in XML. Messages can be formally validated, or simply checked to be well-formed. Messages can be linked to data stored elsewhere, or completely stored internally. Documents can be linked to rule-templates, or be in-built (or no) rules for processing the received data. There is a variety of possibilities (options) as how to integrate EDI with XML. End Users interact with these technical layers through highly visual desktop tools. Developers [use e-commerce components to build these tools.] Peat, B. & Webber, D. August 1997, XML/EDI: The E-business Framework, [Online]. Available: http://www.geocities.com/WallStreet/Floor/5815/startde.htm |
The business model is either of ad hoc interactions between small groups, or agreed upon national or international frameworks, such as those by trade associations or industry bodies.
Figure 3 - XML/EDI Layered Architecture Figure 3 depicts the technical layers that a base XML/EDI system can be built. Not all layers are required to achieve results with XML/EDI. The framework builds upon and enhances the XML and EDI standards and defines the blueprint of EC component interaction. For example, catalog vendors may only want to implement the XML tagging. The tags are defined in "standard" repositories. The various layers support different targeted EC systems. Overall each successive layer provides increasingly more sophisticated capabilities so as to handle more demanding needs. The framework is not a "all-or-nothing" nothing implementation. Each EC component is designed to be able to be used independently -- interfacing with each other as defined by XML/EDI standards. You can create a DTD for formally define the strucuture of EDI messages without having to use it to validate well-formed XML documents. You can simply place EDIFACT/X12 messages in an XML shell element or you can code the message, or parts of it, in XML. You can chose to formally validate messages, or simply check that they are well-formed XML. You can link your messages to data stored elsewhere, or have it all stored intermally. You can link your documents to rule-templates, or have in-built (or no) rules for processing the data you receive. Its up to you how you mix and match the options. End Users interact with these technical layers through highly visual desktop tools. Developers use EC components to build these tools. |
The source is given three times but it is not made clear that the text is so extensively copied - no quotation marks. |
|
| [6.] Svr/Fragment 054 01 - Diskussion Zuletzt bearbeitet: 2020-03-18 16:02:16 Schumann | BauernOpfer, Fragment, Gesichtet, Peat Webber 1997, SMWFragment, Schutzlevel sysop, Svr |
|
|
|
| Untersuchte Arbeit: Seite: 54, Zeilen: 1-4 |
Quelle: Peat Webber 1997 Seite(n): online, Zeilen: 0 |
|---|---|
| Users interface with their documents, as they would use any tool in their desktop applications, wordprocessing, spreadsheets, databases or whatever metaphor is most suited to the application. | Users interface with their documents as they would use any tool in their office support products - word-processing, spreadsheets, databases or whatever metaphor is most suited to the application. |
Continued from previous page, see Fragment 053 01. |
|