• XML as an Information Exchange Format between Applications
  • Microsoft Word Applied xml a toolkit for Programmers Wiley doc




    Download 2,96 Mb.
    Pdf ko'rish
    bet29/131
    Sana14.05.2024
    Hajmi2,96 Mb.
    #232039
    1   ...   25   26   27   28   29   30   31   32   ...   131
    Bog'liq
    Ceponkus, Hoodbhoy - Applied XML - Toolkit for Programmers

    Where Does XML Fit?
    Moving away from the abstract model we outlined in the preceding section, let’s talk 
    technical: What exactly is XML for? The short answer is that XML is a universal, 
    standardized language used to represent data such that it can be both processed 
    independently and exchanged between programs and applications and between clients 
    and servers. The keywords here are 
    information exchange
    .
    Let’s limit our discussion for now to how XML fits in as an information exchange medium 
    between applications and as an information exchange medium between clients and 
    servers.
    XML as an Information Exchange Format between 
    Applications
    Today, organizations possess vast amounts of information in documents. Even so far 
    back as two decades ago most companies accepted that the best way to store data was 
    to digitize it. Companies went about creating electronic documents with the hope that it 
    would cut down on paper-based storage of information and thus avoid all the hassles 
    associated with exchanging information in a paper world (for example, paper degradation 
    and multiple copies). Around the same time, we figured out that certain documents 
    contained standard types of information that could be stored in forms. Furthermore, much 
    of this information could be broken down and stored in fields. From there, databases 
    became a natural extension. Then came a couple of decades of database technology 
    development to the point where now we tend to believe that relational databases are the 
    de facto standard of data storage and retrieval. Figure 2.4 summarizes this process.
    Figure 2.4:
    The move from paper documents to relational databases.
    That takes care of one aspect (some would argue the most important aspect) of 
    collecting, digitizing, and storing data but once you’ve got information, how do you 
    exchange it? That’s not as trivial as it seems. In one sense you’d think, okay, we have 
    tons of 
    data
    , and we know how to sift through it and extract 
    information 
    in an attempt to 
    add to our 
    knowledge
    (for those of you familiar with Information Systems theory, that’s all 
    of it in a nutshell). All that’s left is to present the information to the user. However, the 
    problem is that we don’t have a way of universally trading or 
    exchanging
    data between 
    different users and applications 
    in a format that they can all perform further processing

    After all, what is 
    information
    to one user could just as easily be 
    data
    to another.
    Managing your data is primarily the concern of your database management system, but 
    creating and disseminating information is primarily the responsibility of an organization. 
    How you choose to manipulate data to construct information depends primarily on what 
    format your data is in. The reality is that there is an infinite number of ways of 
    representing data, many of which are intuitive and many more that are counterintuitive 
    yet efficient. If the format of data presented to you is proprietary, then you need 
    corresponding proprietary information on how to decipher that data to manipulate it. You 
    cannot open up a Microsoft Excel spreadsheet and extract information unless you’ve 
    actually got the application programming interfaces (API) to Microsoft Excel.
    If complex simulations are your game, then you often need to perform many independent 


    - 26 -
    operations on the same data. For the following scenario, let’s assume that our data is 
    stored in a common relational database management system, let’s say a SQL Server. 
    You may want to perform both complex statistical analysis and simulation analysis on 
    your data. Programs specifically devoted to each part are available (for instance, Minitab 
    and Arena), and each application is easy to use in its own right. The only problem is that 
    you don’t have a constant way of exchanging information between the two. Minitab 
    processes data in its own native format and Arena does the same. For argument’s sake, 
    let’s say that the results of one are dependent on the other (that is, they need to 
    exchange information between each other). One alternative (and this is what usually 
    happens) is for each program to do more than just one type of processing and to 
    essentially perform the same tasks as the other does, but that’s a really bad solution. It 
    results in a lot of redundant resource allocation as well as maintaining inherent 
    inefficiency; after all, each of these programs is specialized.
    Another solution is for each vendor to create a translation program that allows it to 
    directly access information stored in your database. However, this is more difficult than it 
    sounds, and the vendor has no way of knowing up front that the information you have is 
    stored in Microsoft Access, Oracle, Sybase, or any other DBMS vendor. Figure 2.5 
    summarizes this dilemma.

    Download 2,96 Mb.
    1   ...   25   26   27   28   29   30   31   32   ...   131




    Download 2,96 Mb.
    Pdf ko'rish

    Bosh sahifa
    Aloqalar

        Bosh sahifa



    Microsoft Word Applied xml a toolkit for Programmers Wiley doc

    Download 2,96 Mb.
    Pdf ko'rish