VroniPlag Wiki

This Wiki is best viewed in Firefox with Adblock plus extension.

MEHR ERFAHREN

VroniPlag Wiki
Assessing the Impact of XML/EDI with Real Option Valuation

von Shermin Voshmgir

vorherige Seite | zur Übersichtsseite | folgende Seite

Statistik und Sichtungsnachweis dieser Seite findet sich am Artikelende

[1.] Svr/Fragment 053 01 - Diskussion
Zuletzt bearbeitet: 2020-01-19 22:32:28 Schumann
BauernOpfer, Fragment, Gesichtet, Peat Webber 1997, SMWFragment, Schutzlevel sysop, Svr

Typus
BauernOpfer
Bearbeiter
SleepyHollow02
Gesichtet
Yes
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
Accessed: 28 March 1999.

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.

Anmerkungen

The source is given three times but it is not made clear that the text is so extensively copied - no quotation marks.

Sichter
(SleepyHollow02) Schumann



vorherige Seite | zur Übersichtsseite | folgende Seite
Letzte Bearbeitung dieser Seite: durch Benutzer:Schumann, Zeitstempel: 20200119223348