PATENT ABSTRACT
A system and method for delivering content in real-time using advanced messaging technology that reduces the risk of content being lost or dropped in transmission. The system and method utilize a custom, simplified XML format to deliver real-time textual, numeric, and metadata content directly to subscribers. The XML tag set specifies all of the information needed to package, process, and distribute real-time content messages and includes an advanced tagging structure that allows granular content customization. Messages are built on the fly using multi-channel data processing techniques. The XML delivery system and method offers an array of real-time market-specific page-based “Alert” services and aggregated newswires with accompanying real-time numeric data feeds. These feeds contain proprietary assessments and other price data across a broad spectrum of global and regional commodity markets, including oil, petrochemicals, metals, electric power, natural gas, coal, and risk.

PATENT DESCRIPTION
RELATED APPLICATIONS 
       [0001]    This application claims priority under 35 U.S.C. §119(e) to U.S. Provisional Application Ser. No. 61/369,490, filed Jul. 30, 2010, the disclosure of which is hereby incorporated by reference. 
     
    
     FIELD OF THE INVENTION 
       [0002]    The present invention relates to systems and methods of distributing information items, or content, to channel partners. More particularly, the present invention is directed to a system and method of receiving, packaging, and delivering XML market data to a plurality of subscribers in real-time. 
       BACKGROUND OF INVENTION 
       [0003]    Electronic content publication systems are used to publish digital information items to a plurality of subscribing entities. The publication systems provide information items to multiple, physically separate computerized devices over one or more digital computer networks. These information items may include textual, numeric, or other forms of data, such as, stock quotes, financial data, weather reports, news items, etc. These information, or content, publication systems may be used to disseminate information from a variety of electronic content providers to a variety of subscribing entities (subscribers, vendors, partners), via the interne or other communications networks. 
         [0004]    Industry-standard price assessments are a critical element of short- and long-term commodities contracts worldwide. This information may be published in textual form along with news, market commentary, fundamental data and other useful content. Several product and delivery vehicles may be utilized, such as real-time page-based “Alert” services, as well as end-of-day newswires/newsletters, traditional print newsletters covering different industry segments, or network based content publication services. 
         [0005]    There are a number of challenges that content publication systems must overcome. For example, incoming data must be formatted, in some instances combined, and then associated with the appropriate subscribers entitled to receive that data (known as “packaging” the data). With certain types of data it is critical that each subscriber receive the same data at substantially the same time. Additionally, content publication systems must be able to recognize and deal with failures in information delivery. Furthermore, subscribers do not use the data in the same ways or run the same types of platforms making establishing a standardized data format difficult. 
         [0006]    Existing systems store incoming data for later retrieval and dissemination. At certain intervals, the data is retrieved, associated with the appropriate subscribers, and delivered to subscribers. However, existing systems do not receive multiple types of data and package and distribute it in real-time, i.e., package and distribute a message in response to the receipt of a input data massage. Further, in existing systems, critical market data may be lost or dropped before being delivered to subscribers, due to, for example, network errors or problems with subscribers&#39; servers. In the event that market data cannot be delivered to a subscriber, existing systems do not have the capability to preserve the data until it can be delivered. 
         [0007]    Accordingly, there exists a need for an improved system and method for reliably delivering market data to a plurality of subscribers in real-time. 
       BRIEF SUMMARY OF THE INVENTION 
       [0008]    Aspects of the present invention relate to systems and methods for electronically distributing news, price information, and market data over the internet or other communications network in a simplified, extensible markup language (XML) format to a plurality of subscribers. 
         [0009]    According to an embodiment of the present invention, a system is configured to receive textual and numeric content from at least one source, package the content for delivery to at least one of a plurality of subscribing entities, and publish or otherwise deliver the content via the internet or other communications network. Subscribing entities may include, for example, individual or corporate subscribers, partners, customers, news or information vendors, or any third party information recipient. Numeric content may include numerical analysis such as assessments and other data. For instance, numerical content may include closing market prices and fundamental statistical data as well as time-series data for charting or graphing. Textual content may include news, articles, market commentary, transactions, “market heard” pages, statistics tables, and proprietary assessment and fundamentals tables. 
         [0010]    Preferably, the system comprises one or more computers configured to use a simplified XML tag set to deliver real-time textual and numeric content directly to subscribers in accordance with a real-time permissioning system. This custom tag set specifies all of the information needed to process, package, and distribute real-time content messages and includes an advanced tagging structure that allows granular content customization. 
         [0011]    Embodiments of the present invention offer flexible, reliable and fast delivery of real-time content, including page-based “Alert” services, selected newswires, and proprietary real-time numeric data. These features may be accomplished by combining enterprise messaging technology with an XML message schema. According to one aspect of the invention, data is normalized through the use of at least one filter or flow process and delivered in a standardized format with enough flexibility to allow for future changes. The simple, clean message format of the present invention improves timeliness and reduces processing errors over legacy formats and guarantees messaging that reduces the risk of content being lost or dropped in transmission. 
         [0012]    According to aspects of the present invention, the system and method process and package messages according to Execution Groups, which contain named groupings of message flows. A message flow may be understood as a sequence of nodes, which define the processing steps run by the delivery system of the present invention when an input message is received. For example, a node can represent the set of actions executed by a computer program or processor that define a processing step. 
         [0013]    In accordance with another aspect of the invention, enterprise customers can directly ingest content into their workflow. Furthermore, the invention allows content to be streamed that has traditionally not been delivered by real-time platforms, thereby creating a single consolidated distribution platform for current and future content. 
         [0014]    The present invention provides a real-time content distribution solution using advanced messaging technology that reduces the risk of content being lost or dropped in transmission. 
         [0015]    In accordance with another aspect of the invention, an array of real-time market-specific page-based “Alert” services and aggregated newswires with accompanying real-time numeric data feeds are provided. These feeds contain proprietary assessments and other price data across a broad spectrum of global and regional commodity markets, including oil, petrochemicals, metals, electric power, natural gas, coal, and risk. This content may be delivered using one of three basic XML message formats—textual, numeric or metadata. Additional embodiments of the present invention include metadata and numeric analytics data feeds that include real-time and historic market data. These bulk data feeds provide customers greater flexibility on how and where to leverage the analytics content. 
         [0016]    In accordance with another aspect of the invention, the source information comes from a content publication or generation system, which is used to publish information related to a wide range of markets. The source information is in a standardized format, typically XML 1.0, with a pre-defined set of tags. This information is routed to a delivery system over a communications network, such as an IP network via an IP based messaging protocol, then transformed and processed using a defined set of rules implemented in a rule based engine called a Transform Publish Filter (TPF). The delivery system may then distribute packaged content, or authorize the publication of content messages, based upon a set of distribution rules, such as a subscription permissioning system. For instance, message data, in a second format, usually XML 2.0, is forwarded to the Subscriber hosts over an IP network using the messaging protocol. 
         [0017]    The design of the delivery system provides for ‘end to end’ global delivery, by leveraging standard messaging to deliver content via public networks. The message flow system leverages the messaging system to deliver the feed either over the public network or over a private network. 
         [0018]    In accordance with another aspect of the invention, the TPF rule engine allows real-time application of textual and numeric Business Rules and changes. The message flow architecture allows for maintaining subscription details in real time by processing a permission file as designed by a fulfillment system. For example, a Load Permission File flow can process the permission file in real time whenever there is a change in the incoming permission file by processing the details and updating the database. The fulfillment system may be any external application that supplies a permission file, which may contain, for example, individual subscriber entitlement and package information. This information may be used by the TPF to permission, package, and distribute content in real-time. 
         [0019]    In accordance with another aspect of the invention, the XML structure allows flexibility and agility to customize content in real-time. The message flow architecture allows for enabling or disabling certain tags for a specific partner and for customizing the content to different partners based on their subscription or preference information. 
         [0020]    In accordance with another aspect of the invention, an XML delivery system allows for a complete audit trail, logging, and alert capability in real-time, end to end, up to the delivery point to the end user. For instance, a Send To Audit flow can capture the audit information and a Perfmon results flow can capture the performance details. 
         [0021]    In accordance with another aspect of the invention, content is prioritized for optimal delivery. Different types of messages can be assigned different priorities by the message flow allowing the system to deliver the messages on specified criteria, such as message type or content, rather than in a “first in, first out” format. For example, Price or Numeric messages may be assigned a higher priority than Textual messages so that in the event that two messages are simultaneously being processed, the price or numeric message could be delivered first. 
         [0022]    In accordance with another aspect of the invention, the XML structure described herein can function as an industry standard for commodity news and market data distribution. As will be described in greater detail below, the Document Type Definition (DTD) for the XML structure is unique, and structured to capture the necessary commodity news and market data. 
         [0023]    In accordance with another aspect of the invention, compliance with the XML Standard may be enforced in real-time. The message flow can be configured to raise an exception if an XML message is not in accordance with XML standards. For example, an exception would be raised if an XML message were ill-formed XML without proper closing tags. 
         [0024]    In accordance with another aspect of the invention, metadata is distributed at a desired frequency with all attributes necessary for data ingestion. A metadata flow publishes the price metadata as and when necessary. For example, metadata could be sent once a week or on a demand/need basis. 
         [0025]    In accordance with another aspect of the invention, multiple data types can be processed simultaneously and yet maintain the order of sequence. Specifically, the message flow can process multiple data types in parallel, such as textual, price, and metadata, by filtering the incoming message type and routing them to their associated flows. A dedicated flow, such as a Check Content type flow, can accommodate this functionality. 
         [0026]    In accordance with another aspect of the invention, the tag value code structure design and TPF rule engine together allow for content bundling in real-time. The content delivered to a subscriber can be customized with the ability to bundle only relevant information intended for a particular subscriber instead of sending all the content to all the subscribers. For instance, exemplary nodes “Build Textual data” and “Build Price data” can be configured to check the permissioning for each subscriber and identify the list of subscribers who would get the message. The nodes can also build the messages individually using the &lt;sendTo&gt; tag, with different values, such as: &lt;sendTo&gt;vendor 1 &lt;/sendTo&gt;, &lt;sendTo&gt;vendor 2 &lt;/vendor 2 &gt;, and &lt;sendTo&gt;vendor 3 &lt;/vendor 3 &gt;, etc. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0027]    The accompanying drawings, which are incorporated herein and form part of the specification, illustrate various embodiments of the present invention and, together with the description, further serve to explain the principles of the invention and to enable a person skilled in the pertinent art to make and use the invention. In the drawings, like reference numbers indicate identical or functionally similar elements. 
           [0028]      FIG. 1  is a logical diagram showing the transformation and publication of content to various partners according to an embodiment of the present invention. 
           [0029]      FIG. 2  is a diagram showing the content feed process flow according to an embodiment of the present invention. 
           [0030]      FIG. 3  is a diagram showing an exemplary high-level architecture according to an embodiment of the present invention. 
           [0031]      FIG. 4  is a diagram showing the check content type process flow according to an embodiment of the present invention. 
           [0032]      FIG. 5  is a diagram showing the error handler process flow according to an embodiment of the present invention. 
           [0033]      FIG. 6  is a diagram showing the load permission file process flow according to an embodiment of the present invention. 
           [0034]      FIG. 7  is a diagram showing the load perfmon results process flow according to an embodiment of the present invention. 
           [0035]      FIG. 8  is a diagram showing the send to audit process flow according to an embodiment of the present invention. 
           [0036]      FIG. 9  is a diagram showing the load audit data log process flow according to an embodiment of the present invention. 
           [0037]      FIG. 10  is a diagram showing the structure of an exemplary XML element hierarchy according to an embodiment of the present invention. 
           [0038]      FIG. 11  is an XML Simple Tag Element Hierarchy Diagram in accordance with an embodiment of the present invention. 
           [0039]      FIG. 12  is an XML Textual Element Hierarchy Diagram in accordance with an embodiment of the present invention. 
           [0040]      FIG. 13  is an XML Numeric Element Hierarchy Diagram in accordance with an embodiment of the present invention. 
           [0041]      FIG. 14  is an XML Metadata Element Hierarchy Diagram in accordance with an embodiment of the present invention. 
           [0042]      FIG. 15  is a logical network diagram of a generalized content publication system in accordance with an embodiment of the present invention. 
           [0043]      FIG. 16  is a logical diagram of an XML delivery system in accordance with an embodiment of the present invention. 
           [0044]      FIG. 17  is a logical diagram of the Execution Groups in an XML delivery system in accordance with an embodiment of the present invention. 
           [0045]      FIG. 18  is a logical diagram of a ProcessEWSFeed Message Flow in accordance with an embodiment of the present invention. 
           [0046]      FIG. 19  is a logical diagram of a TextualFlow Message Flow in accordance with an embodiment of the present invention. 
           [0047]      FIG. 20  is a logical diagram of a SubscriberProcessing Message Flow in accordance with an embodiment of the present invention. 
           [0048]      FIG. 21  is a logical diagram of a NumericFlow Message Flow in accordance with an embodiment of the present invention. 
           [0049]      FIG. 22  is a logical diagram of a NumericSubscriberProcessing Message Flow in accordance with an embodiment of the present invention. 
           [0050]      FIG. 23  is a logical diagram of a MetaDataFlow Message Flow in accordance with an embodiment of the present invention. 
           [0051]      FIG. 24  is a logical diagram of a LoadPartner2QueuesMapping Message Flow in accordance with an embodiment of the present invention. 
           [0052]      FIG. 25  is a logical diagram of a LoadPartnerFilteringMapping Message Flow in accordance with an embodiment of the present invention. 
           [0053]      FIG. 26  is a logical diagram of a LoadSubscriberQMapping Message Flow in accordance with an embodiment of the present invention. 
           [0054]      FIG. 27  is a logical diagram of a LoadXMLDDTimeZoneMapping Message Flow in accordance with an embodiment of the present invention. 
           [0055]      FIG. 28  is an illustration of exemplary price output messages in accordance with an embodiment of the present invention. 
           [0056]      FIG. 29  is an illustration of exemplary news story output messages in accordance with an embodiment of the present invention. 
       
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
       [0057]    In accordance with the present invention, the integration of multiple data types is supported. Multiple unique sets of numeric and textual data may be distributed using a similar structure but different tag sets. 
         [0058]    For example, News &amp; Pricing data contains assessments and other data such as closing market prices and fundamental statistical data and is typically distributed using a numeric message format. Use of a numeric message format can support, for example, storage of time-series data for charting, analysis, or other purposes. 
         [0059]    Textual report messages may come in a variety of page sizes to support the distribution of news, market commentary, transactions, and proprietary assessment and fundamentals tables that are pertinent to a defined market. For legacy distribution requirements, a variable length format is used to distribute news articles, market commentary, and legacy newswires, and a fixed length format for proprietary assessment tables, statistical tables, and transaction or “market heard” pages. 
         [0060]    In accordance with the present invention, at least two unique sets of metadata messages can be distributed and associated with these data types. For instance, a first for News &amp; Pricing data and a second for Analytics data. Both message types include permissioning information along with symbol definitions and attributes that are vital to ingesting data. The metadata for Analytics content provides additional information for its associated numeric messages. 
         [0061]    In accordance with an embodiment of the present invention shown in  FIG. 1 , a rule-based engine known as a Transform Publish Filter engine (TPF)  101  is provided. The TPF may be implemented on one or more computers via, for instance, algorithms comprising computer-executable instructions stored on non-transitory computer-readable media. The TPF functions to process, transform and enrich different types of content, including numerical and textual data. Content is received from a content integration source  103  via a messaging server  105 . Once the data has been transformed and processed by the TPF  101 , the content is distributed to a plurality of vendors or partners  107  via a messaging server  109 . 
         [0062]    The TPF  101  applies as series of rules in Process Flow  111  when receiving, transforming, and publishing or otherwise distributing messages. For example, the TPF  101  may be configured to support multiple incoming message types and identify incoming message types through a dedicated flow which, for example, distinguishes between and appropriately routes textual, numeric, and meta data to appropriate nodes. Further, a flow of the TPF may set the message priority for delivery, transform the message to a Standard XML format, and format vendor specific content before delivery. Further, the TPF may include a flow to apply permission rules. For instance, the applied permission rules may be based on a received permission message. Moreover, the TPF can be configured through a series of flows to dynamically update the permission rules whenever there is a new permission message available, log errors, exceptions, and/or un-subscribed messages, and alert or communicate information to a support team. 
         [0063]    Textual and numeric data from a content source are sent to the feed queue on a TPF server. The TPF server may include a number of execution groups. According to an embodiment of the present invention, there are four execution groups in the TPF engine. 
         [0064]    The first, ExecutionGroup 1 , handles all application messages. Once the message type is identified, for instance as textual, numeric, or metadata, the message is routed to the corresponding node in the Process Flow  111 , with specific tags determining its fulfillment criteria (e.g., information regarding how the data should be packaged and delivered). If there are any errors in the XML tag structure, the messages are sent to the error queue and no further processing is done. If the particular item is subscribed to by any partner  107 , individual messages are created for each partner with the subscribed elements in a corresponding XML message. Once all the fulfillment details are identified and mapped, the individual messages for those partners are sent to a queue or distribution list based on these criteria. 
         [0065]    The second, ExecutionGroup 2 , is directed to analytics data processing. Analytics data may arrive via drive mapping as a CSV file, for example. These files are sent to a feed queue and the message flow picks up those messages. Message definitions and sets in the flow are converted into an XML message for the partners. Due to the large amount of data, multiple flows may be used for rapid processing. Several message flow instances are initiated. 
         [0066]    The third, ExecutionGroup 3 , allows purging of the messages on the Partner queues if the messages are not being read. This is a simple execution group containing, for example, purge flows for the various partners  107 . 
         [0067]    Finally, ExecutionGroup 4 , controls the permissions, fulfillment, audit tools, and email utilities for exception handling. This execution group contains miscellaneous utilities such as Auditing, Email Alerts, and Fulfillment flows. Permissioning is used to identify partner subscriptions to each data set (News &amp; Pricing, Analytics, etc.). A fulfillment system generates a permission file and sends the file to a permission feed queue. This message is read by the permission flow and data is refreshed in a database instance in the TPF engine. This data is used, for example, by an Exchange Web Services (EWS) flow to map partners to each incoming message item to determine data recipients. An audit tool determines the number of messages processed. 
         [0068]    More specifically, as shown in  FIG. 2 , a message arrives into the application feed queue node  201  and is routed to a Flow Order  202  node by the TPF engine. The Flow Order  202  node regulates the message flow and routes the message to a CheckEWSType node  204 . 
         [0069]    As shown in  FIG. 4 , the check content type node  204  (CheckEWSType) determines the message type and routes the message to the appropriate node for its message type. For example, this message flow determines whether an XML input message is textual, numeric or metadata by checking for the corresponding tag. This is a commonly used flow across all message flows. Textual messages are recognized by the presence of &lt;page&gt; tag ( 482 ) and are routed for textual processing ( 484 ), for instance, to the Build Textual Data  210  node shown in  FIG. 2 . Price messages are recognized by the presence of the &lt;num&gt; tag ( 486 ) and are routed and processed according to a numeric flow. For instance, price messages may be checked for pricing errors ( 488 ). Similarly, metadata messages may be checked for metadata errors ( 490 ). 
         [0070]    More specifically, the Check Pricing Errors node  208 , shown in  FIG. 2 , checks the message for errors, missing mandatory information (Symbol, DataPoint, PermCode, DateTime, Date, Trans Attributes), and invalid permission codes. It then processes the price point list to send the valid entries and propagate the message to a node for building the price data. 
         [0071]    A Build Price Data node  212  builds the individual messages for each partner based on the permission code and the subscription details in the Permissions table. If there is no vendor subscribing to this category the message is sent to a NOSUBSCRIPTION queue  228 . The node transforms the date format and trans code (to New from Resend for the Future price assessments that are resent the next day) and sends the message to the Vendor Destination node  216 , which in turn routes it the appropriate partner queue(s) depending on the permission file. The message will be sent to an error queue if there are no price point elements. 
         [0072]    The Build Textual Data node  210  validates the tags in the message and builds the individual textual messages for each partner based on the permission code and the subscription details in a Permissions table. If there is no vendor subscribing to this category the message is sent to a NOSUBSCRIPTION queue  228 . If there are vendors subscribing to this category, then node  210  transforms the date format, and appends tags such as service type, service code etc. Exemplary tags according to an aspect of the present invention, including path, description, and applicable rules, are provided in Table 3. The node  210  then builds the individual vendor specific message and then propagates it to the Vendor Destination node  216 . 
         [0073]    A Process MetaData node  214  builds a metadata message, when appropriate, for each partner in a similar fashion to the Build Price Data node and sends the message to the Vendor Destination node  216 . 
         [0074]    The Vendor Destination node  216  routes the message to the appropriate physical queue. An exemplary high-level architecture according to an embodiment of the present invention, including vendors, is shown in  FIG. 3 . This high-level architecture shows a textual and price data generation system in communication with at least one TPF, which is in communication with at least one of a plurality of vendors. If a queue exists, and there are no errors or exceptions to prevent or otherwise interfere with delivery, the Vendor Destination node  216  routes the output message to the Populate Env Fields node  218 . Otherwise the message is sent to the Populate Env Fields On Error node  220 . The Populate Env Fields node  218  prepares the message for auditing. For example, node  218  may set environment variables for auditing purposes. The Populate Env Fields On Error node  220  verifies exceptions and errors to the partner queue and populates the necessary environment fields to send the message to error processing. 
         [0075]    As shown in  FIG. 5 , an error handling node  222  may be used for exception handling and error reporting. For example, this message flow may be configured to receive an error, build an error message, log it to a file for reference, and determine whether to send an email or not based on the log level. According to embodiments of the present invention, this is a flow that can be used across all the message flows. The Build Error Message node  501  forms the error message and logs it. The error message may specify in a text/XML file whether it is an unknown exception or another exception and may specify the timestamp, message id, and the content of the error message. The Log To File node  503  logs the error message and propagates this message to the Send Email node  505 . Depending on the error flag, the Send Email node  505  either logs the message to a Failed-to-send-Mails log  507 , or unsent email queue  509 , or sends it for email output. The Email Output node  511  sends the email to the designated email address via the assigned mail server. Failures and exceptions may be logged, as well as the reason for, or details regarding, any failures in mailerror.log  513 . 
         [0076]    As shown in  FIG. 6 , a Load Permission File Flow may be used to load the permission codes from a fulfillment system into a permissions database  858 . The file received is parsed and the details are uploaded into the database table. The unique design of the TPF rule engine  101  allows real-time application of business rules and business changes. For instance, this message flow architecture allows the system to maintain subscription details in real time by processing the permission file  857 , as designed by the fulfillment system. For example, the Load Permission File message flow may process the permission file  857  in real time whenever there is a change in the incoming permission file  857  by processing the details and updating the permission database  858 . 
         [0077]    As shown in  FIG. 7 , a Perfmon Results Flow may be used to record performance statistics of the delivery system. Performance statistics may include, for example, time to delivery for a vendor or the difference in delivery times between vendors. The audit flow may include checking for a performance flag or other indication of performance. After the audit flow, each message is sent to a performance monitoring queue. If performance monitoring is turned on, the results are built and logged. 
         [0078]    As shown in  FIG. 8 , a Send to Audit Flow  226  is used to log the audit results. After processing for partner transmission, the message is received by the Build Audit Message node  801 , which builds the message needed for audit logging and sends it to the audit log queue  803 . Auditing is turned on by sending the XML messages to ISO and application audit logging utilities. This change can be logged in the audit log as well by using the Log Logger Level node  805 . 
         [0079]    As shown in  FIG. 9 , in an audit data log flow, once the message reaches the Audit Log queue  803 , it is logged and propagated to the Performance Monitoring queue  805  to record performance details. If there are any errors, an error message can be saved. 
         [0080]    An exemplary Messaging Structure according to an embodiment of the present invention is shown in  FIG. 10 . According to an embodiment of the present invention, the system uses the custom, simplified XML tag set shown in  FIG. 10  to deliver real-time textual and numeric content directly to a plurality of subscribers. This XML tag set specifies all of the information needed to package, process, and distribute real time content messages and includes an advanced tagging structure that allows granular content customization and flexibility. 
         [0081]    In this example, the root element of the XML data is the &lt;message&gt; tag. This contains four of six possible child elements: the first, second and third tags—&lt;sendTo&gt;, &lt;sendDt&gt; and &lt;service&gt;—are required in all messages. The fourth tag is either &lt;num&gt; OR &lt;page&gt; OR &lt;metaData&gt;. All real-time messages take one of the following forms: 
         [0082]    Numeric Message Form 
         [0000]    
       
         
               
               
             
           
               
                   
                   
               
             
             
               
                   
                 &lt;message&gt; 
               
               
                   
                   &lt;sendTo&gt; ... &lt;/sendTo&gt; 
               
               
                   
                   &lt;sendDt&gt; ... &lt;/sendDt&gt; 
               
               
                   
                   &lt;service&gt; ... &lt;/service&gt; 
               
               
                   
                   &lt;num&gt; ... &lt;/num&gt; 
               
               
                   
                 &lt;/message&gt; 
               
               
                   
                   
               
             
          
         
       
     
         [0083]    Page Message Form 
         [0000]    
       
         
               
               
             
           
               
                   
                   
               
             
             
               
                   
                 &lt;message&gt; 
               
               
                   
                   &lt;sendTo&gt; ... &lt;/sendTo&gt; 
               
               
                   
                   &lt;sendDt&gt; ... &lt;/sendDt&gt; 
               
               
                   
                   &lt;service&gt; ... &lt;/service&gt; 
               
               
                   
                   &lt;page&gt; ... &lt;/page&gt; 
               
               
                   
                 &lt;/message&gt; 
               
               
                   
                   
               
             
          
         
       
     
         [0084]    Metadata Message Form 
         [0000]    
       
         
               
               
             
           
               
                   
                   
               
             
             
               
                   
                 &lt;message&gt; 
               
               
                   
                   &lt;sendTo&gt; ... &lt;/sendTo&gt; 
               
               
                   
                   &lt;sendDt&gt; ... &lt;/sendDt&gt; 
               
               
                   
                   &lt;service&gt; ... &lt;/service&gt; 
               
               
                   
                   &lt;metaData&gt; ... &lt;/metaData&gt; 
               
               
                   
                 &lt;/message&gt; 
               
               
                   
                   
               
             
          
         
       
     
         [0085]    An XML Tag Element Hierarchy diagram  120  that includes the &lt;message&gt; tag and its children is independently shown in  FIG. 11 .  FIG. 11  shows only those tags that are common to all messages, according to an embodiment of the present invention. 
         [0086]    In  FIG. 12  is an XML Tag Element Hierarchy Diagram  122  illustrating the parent-child relationship of the XML &lt;page&gt; tag used for textual news stories. The &lt;page&gt; tag is not used for numeric or formatted data. 
         [0087]    In  FIG. 13  is an XML Tag Element Hierarchy Diagram  124  illustrating the parent-child relationship of the XML &lt;num&gt; tag used for both News &amp; Pricing and Analytics data through both the &lt;num&gt; and &lt;dataPoint&gt; tags. These messages are similar, except that the Analytics data may include additional attributes. 
         [0088]    In  FIG. 14  is an XML Tag Element Hierarchy Diagram  126  illustrating the parent-child relationship of the XML &lt;metadata&gt; tag used for news and pricing metadata. 
         [0089]    Business Rules 
         [0090]    Textual business rules support the distribution of news, market commentary, transactions, and proprietary assessment and fundamentals tables pertinent to each defined market. These rules may be directed to determining message date and time characteristics, distributing a periodic “Heartbeat” page, setting standard textual page characteristics, including required and optional tags for Textual Pages, assigning unique page identification tags, implementing processing rules such as transmission or storage rules, implementing display rules, providing delete/overwrite instructions, and/or topic and company codes. 
         [0091]    Table 1 includes a listing of exemplary business rules that may be applied by the TPF rule engine for processing textual messages associated with a data feed, such as a real-time XML feed in accordance with the present invention. 
         [0000]    
       
         
               
             
               
               
               
               
             
           
               
                 TABLE 1 
               
             
             
               
                   
               
               
                 Textual Business Rules 
               
             
          
           
               
                   
                 Message 
                   
                   
               
               
                 Rule ID 
                 Type 
                 Short Description 
                 Rule(s) 
               
               
                   
               
               
                 BRPL01 
                 Text 
                 Message date and time 
                 Unless otherwise stated, use 
               
               
                   
                   
                 characteristics 
                 &lt;sendDt&gt; as the master timestamp to 
               
               
                   
                   
                   
                 store textual message content. 
               
               
                 BRPL02 
                 Text 
                 XML DD “heartbeat” 
                 System distributes a “heartbeat” page 
               
               
                   
                   
                 page 
                 every three (3) minutes using the 
               
               
                   
                   
                   
                 values &lt;cSource&gt; = “PGA” and 
               
               
                   
                   
                   
                 &lt;pageNumber&gt; = “0242” to verify 
               
               
                   
                   
                   
                 connectivity. The heartbeat should 
               
               
                   
                   
                   
                 never be displayed on the user screen. 
               
               
                 BRPL03 
                 Text 
                 Standard textual page 
                 BRPL03.1 &lt;message&gt; &lt;page&gt; 
               
               
                   
                   
                 characteristics 
                 identifies the message as a textual 
               
               
                   
                   
                   
                 page. 
               
               
                   
                   
                   
                 BRPL03.2 Maximum page width = 
               
               
                   
                   
                   
                 80 columns 
               
               
                   
                   
                   
                 BRPL03.3 Maximum headline width = 
               
               
                   
                   
                   
                 120 columns 
               
               
                   
                   
                   
                 BRPL03.4 Page length is determined 
               
               
                   
                   
                   
                 by the content; it does not exceed 
               
               
                   
                   
                   
                 twelve (12) kb (approximately 320 
               
               
                   
                   
                   
                 rows). 
               
               
                 BRPL04 
                 Text 
                 Required tags for 
                 All textual Page transmissions must 
               
               
                   
                   
                 Textual Pages 
                 contain the following tags: 
               
               
                   
                   
                   
                 &lt;message&gt;, &lt;sendTo&gt;, &lt;sendDt&gt;, 
               
               
                   
                   
                   
                 &lt;service&gt;, &lt;page&gt;, &lt;headLine&gt;, 
               
               
                   
                   
                   
                 &lt;date&gt;, &lt;pageNumber&gt;, &lt;sid&gt;, and 
               
               
                   
                   
                   
                 &lt;cSource&gt;. 
               
               
                 BRPL05 
                 Text 
                 Optional tags for 
                 Textual Page transmissions can 
               
               
                   
                   
                 Textual Page 
                 contain any of the following tags: 
               
               
                   
                   
                   
                 &lt;textBody&gt;, &lt;dateLine&gt;, &lt;author&gt;, 
               
               
                   
                   
                   
                 &lt;banner&gt;, &lt;company&gt;, &lt;topic&gt;, 
               
               
                   
                   
                   
                 &lt;cSource2&gt;, &lt;serviceCode&gt;, 
               
               
                   
                   
                   
                 &lt;pCategory&gt;, &lt;cont&gt;, &lt;delete&gt;, 
               
               
                   
                   
                   
                 &lt;flash&gt;, &lt;flashFollow&gt;, &lt;overWrite&gt;, 
               
               
                   
                   
                   
                 and &lt;take&gt;. 
               
               
                 BRPL06 
                 Text 
                 Unique Page 
                 BRPL06.1 Each page is uniquely 
               
               
                   
                   
                 Identification 
                 identified by the combination of the 
               
               
                   
                   
                   
                 &lt;cSource&gt;, &lt;pageNumber&gt; and &lt;sid&gt; 
               
               
                   
                   
                   
                 tags. 
               
               
                   
                   
                   
                 BRPL06.2 Pages are identified by 
               
               
                   
                   
                   
                 concatenating the &lt;cSource&gt; and 
               
               
                   
                   
                   
                 &lt;pageNumber&gt; tags for storage and 
               
               
                   
                   
                   
                 recall purposes. The &lt;sid&gt; tag 
               
               
                   
                   
                   
                 differentiates versions of each page 
               
               
                   
                   
                   
                 BRPL06.3 A sequential &lt;sid&gt; value 
               
               
                   
                   
                   
                 is assigned to every textual page 
               
               
                   
                   
                   
                 transmission, independent of the 
               
               
                   
                   
                   
                 underlying textual content. The &lt;sid&gt; 
               
               
                   
                   
                   
                 values repeat after 999,999 page 
               
               
                   
                   
                   
                 transmissions. This happens 
               
               
                   
                   
                   
                 approximately monthly. 
               
               
                   
                   
                   
                 BRPL06.4 If a published page needs 
               
               
                   
                   
                   
                 to be corrected or deleted pursuant to 
               
               
                   
                   
                   
                 BRPL14 or 15 below, XML DD will 
               
               
                   
                   
                   
                 do so within a few days of the original 
               
               
                   
                   
                   
                 page transmission to ensure the 
               
               
                   
                   
                   
                 correct &lt;sid&gt;, &lt;cSource&gt;, 
               
               
                   
                   
                   
                 &lt;pageNumber&gt; combination can be 
               
               
                   
                   
                   
                 found. 
               
               
                 BRPL07 
                 Text 
                 How to process pages 
                 BRPL07.1 If a page transmission 
               
               
                   
                   
                 that include the 
                 includes the &lt;cSource2&gt; tag, then 
               
               
                   
                   
                 &lt;cSource2&gt; tag 
                 replicate the content for each service 
               
               
                   
                   
                   
                 identified. This is in addition to the 
               
               
                   
                   
                   
                 normal processing of the &lt;cSource&gt; 
               
               
                   
                   
                   
                 value. 
               
               
                   
                   
                   
                 BRPL07.2 Each value in the 
               
               
                   
                   
                   
                 &lt;cSource2&gt; tag should be combined 
               
               
                   
                   
                   
                 with the &lt;pageNumber&gt; and &lt;sid&gt; 
               
               
                   
                   
                   
                 tags to form the additional unique 
               
               
                   
                   
                   
                 pages. 
               
               
                   
                   
                   
                 BRPL07.3 Each unique combination 
               
               
                   
                   
                   
                 should be stored independently for 
               
               
                   
                   
                   
                 recall by the user. 
               
               
                   
                   
                   
                 BRPL07.4 (Subscribers only): 
               
               
                   
                   
                   
                 Apply user permissions identified in 
               
               
                   
                   
                   
                 the &lt;cSource&gt; or &lt;cSource2&gt; tags to 
               
               
                   
                   
                   
                 each unique page as further defined in 
               
               
                   
                   
                   
                 BRPL16. 
               
               
                 BRPL08 
                 Text 
                 XML DD Newswire 
                 BRPL08.1 Newswires often exceed 
               
               
                   
                   
                 pages 
                 the maximum file size and/or page 
               
               
                   
                   
                   
                 height allowed by most systems. 
               
               
                   
                   
                   
                 Therefore, XML DD breaks 
               
               
                   
                   
                   
                 individual Newswire transmissions 
               
               
                   
                   
                   
                 into multiple smaller pages. 
               
               
                   
                   
                   
                 BRPL08.2 XML DD embeds codes 
               
               
                   
                   
                   
                 in the &lt;topic&gt; tag in each individual 
               
               
                   
                   
                   
                 page transmission. These tags contain 
               
               
                   
                   
                   
                 instructions for building the newswire 
               
               
                   
                   
                   
                 from the individual pages. This allows 
               
               
                   
                   
                   
                 end-users to view an entire newswire 
               
               
                   
                   
                   
                 as a single story at the user interface. 
               
               
                   
                   
                   
                 BRPL 08.3 To view a newswire as a 
               
               
                   
                   
                   
                 single story, systems should process 
               
               
                   
                   
                   
                 the &lt;topic&gt; tag codes as follows: 
               
               
                   
                   
                   
                 Topic codes are in the following 
               
               
                   
                   
                   
                 format: 
               
               
                   
                   
                   
                 P###S#O# 
               
               
                   
                   
                   
                 “P” stands for “Page” 
               
               
                   
                   
                   
                 “###” represents the starting 
               
               
                   
                   
                   
                 page number of the sequence 
               
               
                   
                   
                   
                 “S#O#”; S# = the current 
               
               
                   
                   
                   
                 page&#39;s sequence number 
               
               
                   
                   
                   
                 “O = of” and the second “#” = 
               
               
                   
                   
                   
                 the total number of pages in 
               
               
                   
                   
                   
                 the group. 
               
               
                   
                   
                   
                 Append each sequential page 
               
               
                   
                   
                   
                 (“S#”) in a series, as defined by 
               
               
                   
                   
                   
                 the “P###” combination for any 
               
               
                   
                   
                   
                 unique &lt;cSource&gt; to the previous 
               
               
                   
                   
                   
                 sequential page with the same 
               
               
                   
                   
                   
                 topic code (but with a different 
               
               
                   
                   
                   
                 sequence number). 
               
               
                   
                   
                   
                 To identify the final Newswire 
               
               
                   
                   
                   
                 sequence, concatenate the &lt;cSource&gt; 
               
               
                   
                   
                   
                 and &lt;pageNumber&gt; values from the 
               
               
                   
                   
                   
                 first page in the series pursuant to 
               
               
                   
                   
                   
                 BRPL06. 
               
               
                 BRPL09 
                 Text 
                 How to display a textual 
                 BRPL09.1 A textual Story must 
               
               
                   
                   
                 Story on a terminal or 
                 display the &lt;headLine&gt; followed by 
               
               
                   
                   
                 client application 
                 the &lt;textBody&gt; and then the 
               
               
                   
                   
                   
                 &lt;banner&gt;. 
               
               
                   
                   
                   
                 BRPL09.2 The &lt;banner&gt; tag defines 
               
               
                   
                   
                   
                 the service name. It is center-aligned 
               
               
                   
                   
                   
                 at the bottom immediately after 
               
               
                   
                   
                   
                 &lt;textBody&gt; 
               
               
                 BRPL10 
                 Text 
                 How to display a textual 
                 BRPL10.1 XML DD distributes 
               
               
                   
                   
                 Story containing 
                 textual pages in multiple messages, 
               
               
                   
                   
                 continuation pages on a 
                 using a &lt;cont&gt; tag to identify the 
               
               
                   
                   
                 terminal or client 
                 follow-on or continuation page. The 
               
               
                   
                   
                 application 
                 value in the &lt;cont&gt; tag corresponds to 
               
               
                   
                   
                   
                 the 1-4 digit page number of the next 
               
               
                   
                   
                   
                 page. Please note: the 1-4 digit page 
               
               
                   
                   
                   
                 number is not always the same as the 
               
               
                   
                   
                   
                 &lt;pageNumber&gt; tag value. It may also 
               
               
                   
                   
                   
                 include a &lt;cSource&gt; reference. 
               
               
                   
                   
                   
                 BRPL10.2 The &lt;cSource&gt; or 
               
               
                   
                   
                   
                 &lt;cSource2&gt; value of the originating 
               
               
                   
                   
                   
                 page should always be the same as the 
               
               
                   
                   
                   
                 continuation page. 
               
               
                   
                   
                   
                 BRPL10.3 Each page in a 
               
               
                   
                   
                   
                 continuation series can also contain a 
               
               
                   
                   
                   
                 &lt;take&gt; tag that identifies the sequence 
               
               
                   
                   
                   
                 number of the associated page and the 
               
               
                   
                   
                   
                 starting page number of the sequence 
               
               
                   
                   
                   
                 separated by a space. 
               
               
                   
                   
                   
                 BRPL10.4 The &lt;take&gt; and &lt;cont&gt; 
               
               
                   
                   
                   
                 tags are displayed in the footer of the 
               
               
                   
                   
                   
                 associated story page along with the 
               
               
                   
                   
                   
                 &lt;banner&gt; tag. The &lt;take&gt; is aligned 
               
               
                   
                   
                   
                 to the far left of the footer, &lt;banner&gt; 
               
               
                   
                   
                   
                 is in the middle and &lt;cont&gt; is to the 
               
               
                   
                   
                   
                 far right. 
               
               
                   
                   
                   
                 Note: Some applications allow the 
               
               
                   
                   
                   
                 user to navigate to the next page by 
               
               
                   
                   
                   
                 clicking the &lt;take&gt; or &lt;cont&gt; values 
               
               
                   
                   
                   
                 within the footer. 
               
               
                 BRPL11 
                 Text 
                 How to identify and 
                 BRPL11.1 Messages with a NULL- 
               
               
                   
                   
                 process a Newsflash 
                 valued &lt;flash&gt; tag are News Flashes. 
               
               
                   
                   
                 textual message 
                 News Flashes are urgent headlines 
               
               
                   
                   
                   
                 sent while XML DD editors develop 
               
               
                   
                   
                   
                 the full story. 
               
               
                   
                   
                   
                 BRPL11.2 XML DD follows most 
               
               
                   
                   
                   
                 News Flash pages with a “Flash- 
               
               
                   
                   
                   
                 Follow” page within five (5) to sixty 
               
               
                   
                   
                   
                 (60) minutes of the News Flash 
               
               
                   
                   
                   
                 transmission. 
               
               
                   
                   
                   
                 BRPL11.3 The Flash Follow 
               
               
                   
                   
                   
                 ALWAYS contains the same &lt;sid&gt;, 
               
               
                   
                   
                   
                 &lt;cSource&gt;/&lt;cSource2&gt;, and 
               
               
                   
                   
                   
                 &lt;pageNumber&gt; values as the original 
               
               
                   
                   
                   
                 News Flash. 
               
               
                   
                   
                   
                 BRPL11.4 A Flash Follow usually 
               
               
                   
                   
                   
                 contains the same &lt;headLine&gt; value 
               
               
                   
                   
                   
                 as the News Flash. However, XML 
               
               
                   
                   
                   
                 DD may distribute a News Flash 
               
               
                   
                   
                   
                 without a “Flash-Follow”. 
               
               
                 BRPL12 
                 Text 
                 How to identify and 
                 BRPL12.1 Any message with a 
               
               
                   
                   
                 store a Flash-Follow 
                 NULL-valued &lt;flashFollow&gt; tag is a 
               
               
                   
                   
                 textual message 
                 Flash Follow. A Flash Follow is an 
               
               
                   
                   
                   
                 update to a News Flash. 
               
               
                   
                   
                   
                 BRPL12.2 Since a Flash Follow is an 
               
               
                   
                   
                   
                 update to a News Flash, XML DD 
               
               
                   
                   
                   
                 requires subscribers to append the 
               
               
                   
                   
                   
                 &lt;textBody&gt; of the Flash Follow to the 
               
               
                   
                   
                   
                 original stored News Flash. 
               
               
                   
                   
                   
                 BRPL12.3 A Flash Follow contains 
               
               
                   
                   
                   
                 the same &lt;sid&gt;, &lt;cSource&gt; and/or 
               
               
                   
                   
                   
                 &lt;cSource2&gt;, and &lt;pageNumber&gt; 
               
               
                   
                   
                   
                 values as the original News Flash. 
               
               
                   
                   
                   
                 BRPL12.4 The &lt;textBody&gt; of the 
               
               
                   
                   
                   
                 original News Flash message (if one 
               
               
                   
                   
                   
                 was sent) with matching &lt;sid&gt;, 
               
               
                   
                   
                   
                 &lt;cSource&gt; and/or &lt;cSource2&gt; and 
               
               
                   
                   
                   
                 &lt;pageNumber&gt; values should be 
               
               
                   
                   
                   
                 replaced with the &lt;textBody&gt; of the 
               
               
                   
                   
                   
                 Flash Follow message and remain 
               
               
                   
                   
                   
                 stored relative to the &lt;sendDt&gt; of the 
               
               
                   
                   
                   
                 original News Flash message. 
               
               
                   
                   
                   
                 BRPL12.5 In addition to BRPL12.3, 
               
               
                   
                   
                   
                 the Flash Follow message should also 
               
               
                   
                   
                   
                 be stored as an independent new 
               
               
                   
                   
                   
                 message relative to the &lt;sendDt&gt; 
               
               
                   
                   
                   
                 value of the Flash Follow message. 
               
               
                 BRPL13 
                 Text 
                 How to display of a 
                 BRPL13.1 Subscriber platforms 
               
               
                   
                   
                 News Flash Headline 
                 MUST differentiate News Flash 
               
               
                   
                   
                   
                 headlines from normal headlines. 
               
               
                   
                   
                   
                 Note: This can be achieved in 
               
               
                   
                   
                   
                 numerous ways. For example by 
               
               
                   
                   
                   
                 using different text font/color for 
               
               
                   
                   
                   
                 News Flashes, using “Alert”-style 
               
               
                   
                   
                   
                 pop-up windows, etc. 
               
               
                   
                   
                   
                 BRPL13.2 XML DD requires 
               
               
                   
                   
                   
                 subscriber platforms to insert the 
               
               
                   
                   
                   
                 word “NEWSFLASH:” in front of 
               
               
                   
                   
                   
                 the value for the &lt;headLine&gt; tag of a 
               
               
                   
                   
                   
                 News Flash. 
               
               
                 BRPL14 
                 Text 
                 How to identify and 
                 BRPL14.1 A DSI message is an 
               
               
                   
                   
                 process a Delete Story 
                 instruction to delete a previously sent 
               
               
                   
                   
                 Instruction (DSI) 
                 textual message and includes a 
               
               
                   
                   
                 message 
                 NULL-valued &lt;delete /&gt; tag. 
               
               
                   
                   
                   
                 BRPL14.2 Upon receipt of a DSI 
               
               
                   
                   
                   
                 message, search for a previous textual 
               
               
                   
                   
                   
                 message with matching &lt;cSource&gt; / 
               
               
                   
                   
                   
                 &lt;cSource2&gt;, &lt;pageNumber&gt; and 
               
               
                   
                   
                   
                 &lt;sid&gt; values and delete the original 
               
               
                   
                   
                   
                 message completely. 
               
               
                   
                   
                   
                 BRPL14.3 An explanation of the 
               
               
                   
                   
                   
                 reason for the deletion may be 
               
               
                   
                   
                   
                 contained in the &lt;textBody&gt; tag of 
               
               
                   
                   
                   
                 the DSI message. 
               
               
                   
                   
                   
                 BRPL14.4 A DSI can only occur 
               
               
                   
                   
                   
                 within 24 hours following distribution 
               
               
                   
                   
                   
                 of the original textual message. 
               
               
                 BRPL15 
                 Text 
                 How to identify and 
                 BRPL15.1 An OSI message is an 
               
               
                   
                   
                 process an Overwrite 
                 instruction to overwrite a previously 
               
               
                   
                   
                 Story Instruction (OSI) 
                 sent textual message and includes a 
               
               
                   
                   
                   
                 NULL-valued &lt;overWrite /&gt; tag. 
               
               
                   
                   
                   
                 BRPL15.2 Upon receipt of an OSI 
               
               
                   
                   
                   
                 message, search for a previous textual 
               
               
                   
                   
                   
                 message with matching &lt;cSource&gt; / 
               
               
                   
                   
                   
                 &lt;cSource2&gt;, &lt;pageNumber&gt; and 
               
               
                   
                   
                   
                 &lt;sid&gt; values and overwrite the 
               
               
                   
                   
                   
                 original message with the new OSI 
               
               
                   
                   
                   
                 message. 
               
               
                   
                   
                   
                 BRPL15.3 An OSI can occur up to 
               
               
                   
                   
                   
                 seven (7) days after the original story 
               
               
                   
                   
                   
                 transmission. 
               
               
                   
                   
                   
                 BRPL15.4 An explanation of the 
               
               
                   
                   
                   
                 reason for the OSI message may be 
               
               
                   
                   
                   
                 contained in the &lt;textBody&gt; of the 
               
               
                   
                   
                   
                 OSI. 
               
               
                 BRPL16 
                 Text 
                 How to permission 
                 XML DD affixes tags that can be used 
               
               
                   
                   
                 textual content 
                 to filter and/or provision content to 
               
               
                   
                   
                 (Subscribers only) 
                 end-users. 
               
               
                   
                   
                   
                 BRPL16.1 Most Legacy subscriber 
               
               
                   
                   
                   
                 platforms filter content for 
               
               
                   
                   
                   
                 provisioning XML DD services using 
               
               
                   
                   
                   
                 the &lt;cSource&gt;/ &lt;cSource2&gt; tags. 
               
               
                   
                   
                   
                 Only messages containing a product 
               
               
                   
                   
                   
                 or service value matching an 
               
               
                   
                   
                   
                 individual user&#39;s permissions, as 
               
               
                   
                   
                   
                 provided by XML DD, should be 
               
               
                   
                   
                   
                 accessible by the user. 
               
               
                   
                   
                   
                 BRPL16.2 XML DD introduced the 
               
               
                   
                   
                   
                 new &lt;serviceCode&gt; tag to replace the 
               
               
                   
                   
                   
                 use of &lt;cSource&gt; and &lt;cSource2&gt; for 
               
               
                   
                   
                   
                 provisioning XML DD services. The 
               
               
                   
                   
                   
                 &lt;serviceCode&gt; tag contains one or 
               
               
                   
                   
                   
                 more pre-defined XML DD service 
               
               
                   
                   
                   
                 codes corresponding to the target 
               
               
                   
                   
                   
                 product or service. Only messages 
               
               
                   
                   
                   
                 containing a product or service value 
               
               
                   
                   
                   
                 matching an individual user&#39;s 
               
               
                   
                   
                   
                 permissions, as provided by XML 
               
               
                   
                   
                   
                 DD, should be accessible by the user. 
               
               
                   
                   
                   
                 BRPL16.3 XML DD is introducing a 
               
               
                   
                   
                   
                 &lt;permissionCode&gt; tag for future 
               
               
                   
                   
                   
                 provisioning of XML DD services. 
               
               
                   
                   
                   
                 This will segregate each service into 
               
               
                   
                   
                   
                 smaller groups of pages that can be 
               
               
                   
                   
                   
                 bundled to build a product or service 
               
               
                   
                   
                   
                 using one or more &lt;permissionCode&gt; 
               
               
                   
                   
                   
                 values. This will require subscribers 
               
               
                   
                   
                   
                 to maintain mappings of individual 
               
               
                   
                   
                   
                 &lt;permissionCode&gt; values that 
               
               
                   
                   
                   
                 comprise a product or service and 
               
               
                   
                   
                   
                 filter messages to the end user 
               
               
                   
                   
                   
                 accordingly. 
               
               
                 BRPL17 
                 Text 
                 Topic codes 
                 BRPL17.1 XML DD uses the &lt;topic&gt; 
               
               
                   
                   
                   
                 tag to distribute topic codes 
               
               
                   
                   
                   
                 BRPL17.2 Topic codes indicate that 
               
               
                   
                   
                   
                 the content belongs to specific 
               
               
                   
                   
                   
                 categories such as geographical 
               
               
                   
                   
                   
                 regions, and/or general subjects or 
               
               
                   
                   
                   
                 markets. Users typically use Topic 
               
               
                   
                   
                   
                 codes to filter the content at the user 
               
               
                   
                   
                   
                 interface. 
               
               
                 BRPL18 
                 Text 
                 Specialty Topic Codes 
                 If &lt;topic&gt; = “XXX” the listening 
               
               
                   
                   
                   
                 service or platform should omit the 
               
               
                   
                   
                   
                 story from any scrolling headline 
               
               
                   
                   
                   
                 stack(s) at the user interface level 
               
               
                   
                   
                   
                 only. 
               
               
                 BRPL19 
                 Text 
                 Company Codes 
                 The &lt;company&gt; tag is used to 
               
               
                   
                   
                   
                 disseminate codes within textual 
               
               
                   
                   
                   
                 messages corresponding to a specific 
               
               
                   
                   
                   
                 company or other entity. This code is 
               
               
                   
                   
                   
                 typically used to filter textual content. 
               
               
                 BRPL27 
                 Text 
                 News page Corrections 
                 BRPL20.1 A Correction message is 
               
               
                   
                   
                   
                 an instruction to overwrite a 
               
               
                   
                   
                   
                 previously sent textual message and 
               
               
                   
                   
                   
                 includes a NULL-valued &lt;correct /&gt; 
               
               
                   
                   
                   
                 tag. 
               
               
                   
                   
                   
                 BRPL20.2 Upon receipt of a 
               
               
                   
                   
                   
                 Correction message, search for a 
               
               
                   
                   
                   
                 previous textual message with 
               
               
                   
                   
                   
                 matching &lt;cSource&gt; / &lt;cSource2&gt;, 
               
               
                   
                   
                   
                 &lt;pageNumber&gt; and &lt;sid&gt; values and 
               
               
                   
                   
                   
                 overwrite the original message with 
               
               
                   
                   
                   
                 the new Correction message. 
               
               
                   
                   
                   
                 BRPL20.3 A Correction can occur up 
               
               
                   
                   
                   
                 to seven (7) days after the original 
               
               
                   
                   
                   
                 story transmission. 
               
               
                   
                   
                   
                 BRPL20.4 An explanation of the 
               
               
                   
                   
                   
                 reason for the Correction message 
               
               
                   
                   
                   
                 may be contained in the &lt;textBody&gt; 
               
               
                   
                   
                   
                 of the Correction 
               
               
                   
                   
                   
                 BRPL20.5 When a Correction is 
               
               
                   
                   
                   
                 received, it should be displayed 
               
               
                   
                   
                   
                 relative to the &lt;sendDate&gt; value of 
               
               
                   
                   
                   
                 the latest Correction. Any reference 
               
               
                   
                   
                   
                 to the original message should be 
               
               
                   
                   
                   
                 removed. 
               
               
                   
               
             
          
         
       
     
         [0092]    Similar to the Textual Business rules, Numeric Business rules support the distribution of News &amp; Pricing data as well as Analytics data. These rules may be related to, for example, identifying a numeric price message, process and storing date references for numeric updates, identifying message transaction type, identifying and processing a deletion, determining permission for numeric content, identifying price value confidence, and/or differentiating data delivery timing. 
         [0093]    Table 2 includes exemplary business rules that may be applied by the TPF rule engine for processing numeric messages associated with a data feed, such as a real-time XML feed in accordance with the present invention. Some of the rules may apply to all numeric message types, while others may be more applicable to only news and pricing or analytics data. 
         [0000]    
       
         
               
             
               
               
               
               
             
               
               
               
             
               
               
               
               
             
           
               
                 TABLE 2 
               
             
             
               
                   
               
               
                 Numeric Business Rules 
               
             
          
           
               
                 Short 
                 Message 
                   
                   
               
               
                 Description 
                 Type 
                 Short Description 
                 Short Description 
               
               
                   
               
               
                 BRPL20 
                 News &amp; 
                 How to identify a 
                 Numeric transmissions must 
               
               
                   
                 Pricing; 
                 numeric price message 
                 contain the following tags: 
               
               
                   
                 Analytics 
                   
                 &lt;message&gt;, &lt;sendTo&gt;, &lt;sendDt&gt;, 
               
               
                   
                   
                   
                 &lt;service&gt;, &lt;num&gt; and &lt;dataPoint&gt; 
               
               
                 BRPL21 
                 News &amp; 
                 How to process and 
                 BRPL21.1 The &lt;sendDt&gt; tag 
               
               
                   
                 Pricing; 
                 store date references 
                 provides the date and time that 
               
               
                   
                 Analytics 
                 for numeric updates 
                 XML DD distributed the update. 
               
               
                   
                   
                   
                 BRPL21.2 The dateTime attribute 
               
               
                   
                   
                   
                 of the &lt;dataPoint&gt; tag provides the 
               
               
                   
                   
                   
                 date and time to update the 
               
               
                   
                   
                   
                 associated time series database. 
               
               
                 BRPL22 
                 News &amp; 
                 How to identify the 
                 All numeric messages include a 
               
               
                   
                 Pricing 
                 message transaction 
                 trans attribute defining the 
               
               
                   
                   
                 type 
                 “transaction” type. 
               
             
          
           
               
                   
                 trans value 
                 Description 
               
               
                   
                 C 
                 Correction 
               
               
                   
                 N 
                 New Update 
               
               
                   
                 D 
                 Delete 
               
               
                   
                 R 
                 Resend 
               
             
          
           
               
                 BRPL23 
                 News &amp; 
                 How to identify and 
                 A &lt;dataPoint&gt; value = “−999999” 
               
               
                   
                 Pricing 
                 process a deletion 
                 that includes a trans attribute with a 
               
               
                   
                   
                   
                 value = “D” (delete) means the 
               
               
                   
                   
                   
                 associated instrument update, 
               
               
                   
                   
                   
                 including the date, should be 
               
               
                   
                   
                   
                 deleted from the database. 
               
               
                 BRPL24 
                 News &amp; 
                 How to permission 
                 XML DD includes several attributes 
               
               
                   
                 Pricing 
                 numeric content 
                 that can be used to filter and/or 
               
               
                   
                   
                 (Subscribers only) 
                 provision numeric content to end- 
               
               
                   
                   
                   
                 users. 
               
               
                   
                   
                   
                 BRPL24.1 Each numeric message 
               
               
                   
                   
                   
                 contains a permCode attribute, 
               
               
                   
                   
                   
                 containing a data category. This 
               
               
                   
                   
                   
                 attribute is used to bundle groups of 
               
               
                   
                   
                   
                 instruments into price data 
               
               
                   
                   
                   
                 packages. Proper processing and 
               
               
                   
                   
                   
                 storage of this field is required. 
               
               
                   
                   
                   
                 XML DD can provide detailed 
               
               
                   
                   
                   
                 package definitions upon request. 
               
               
                 BRPL25 
                 Analytics 
                 How to identify the 
                 Currently, most ISOs report only 
               
               
                   
                   
                 price value confidence 
                 preliminary and settlement prices. 
               
               
                   
                   
                   
                 Preliminary prices are reported first. 
               
               
                   
                   
                   
                 One ISO-PJM-also reports 
               
               
                   
                   
                   
                 ‘ADVISORY’ prices, which are 
               
               
                   
                   
                   
                 followed by ‘PRELIMINARY’ and 
               
               
                   
                   
                   
                 then ‘SETTLEMENT’ prices. In the 
               
               
                   
                   
                   
                 future, more ISOs are likely to 
               
               
                   
                   
                   
                 adopt ‘ADVISORY’ prices. 
               
               
                   
                   
                   
                 For example, 
               
               
                   
                   
                   
                 Every hour, a price for a subset 
               
               
                   
                   
                   
                 of PODs is reported. These are 
               
               
                   
                   
                   
                 considered “ADVISORY” 
               
               
                   
                   
                   
                 prices. 
               
               
                   
                   
                   
                 At the start of each business 
               
               
                   
                   
                   
                 day, PJM releases 
               
               
                   
                   
                   
                 “PRELIMINARY” prices for 
               
               
                   
                   
                   
                 the previous day. Any record 
               
               
                   
                   
                   
                 that had an ADVISORY price 
               
               
                   
                   
                   
                 reported gets updated with the 
               
               
                   
                   
                   
                 PRELIMINARY price. If there 
               
               
                   
                   
                   
                 was no ADVISORY for a POD, 
               
               
                   
                   
                   
                 a new record is created. Most, 
               
               
                   
                   
                   
                 but not all, PODs have 
               
               
                   
                   
                   
                 Preliminary prices. 
               
               
                   
                   
                   
                 On the fourth or fifth business 
               
               
                   
                   
                   
                 day of the month, 
               
               
                   
                   
                   
                 “SETTLEMENT” prices are 
               
               
                   
                   
                   
                 released for the previous month. 
               
               
                   
                   
                   
                 Any record having an 
               
               
                   
                   
                   
                 ADVISORY or 
               
               
                   
                   
                   
                 PRELIMINARY price will be 
               
               
                   
                   
                   
                 updated with the 
               
               
                   
                   
                   
                 SETTLEMENT price. If there 
               
               
                   
                   
                   
                 was no ADVISORY or 
               
               
                   
                   
                   
                 PRELIMINARY price for a 
               
               
                   
                   
                   
                 POD, a new record is created. 
               
               
                   
                   
                   
                 Not all PODs have settlement 
               
               
                   
                   
                   
                 prices. 
               
               
                 BRPL26 
                 News &amp; 
                 How to differentiate 
                 XML DD maintains data delivery 
               
               
                   
                 Pricing or 
                 data delivery timing 
                 business models based on the timing 
               
               
                   
                 Analytics 
                 for a specific user 
                 of delivery to an end-user, e.g. 
               
               
                   
                   
                   
                 XML DD Market Data uses 
               
               
                   
                   
                   
                 multiple “cut-times” to deliver 
               
               
                   
                   
                   
                 different regional data categories, 
               
               
                   
                   
                   
                 whereas the same data is distributed 
               
               
                   
                   
                   
                 in real-time via this XML data feed. 
               
               
                   
                   
                   
                 To differentiate business models, 
               
               
                   
                   
                   
                 XML DD introduced the “type” and 
               
               
                   
                   
                   
                 “releaseTime” children to the 
               
               
                   
                   
                   
                 &lt;service&gt; tag. The “type” value 
               
               
                   
                   
                   
                 corresponds to the business model, 
               
               
                   
                   
                   
                 while the “releaseTime” value 
               
               
                   
                   
                   
                 corresponds to the time that the data 
               
               
                   
                   
                   
                 may be released to users of the 
               
               
                   
                   
                   
                 corresponding service “type”. 
               
               
                   
                   
                   
                 Consumers that wish to consolidate 
               
               
                   
                   
                   
                 receipt of XML DD content on the 
               
               
                   
                   
                   
                 XML feed and support/offer 
               
               
                   
                   
                   
                 multiple XML DD business models 
               
               
                   
                   
                   
                 must do the following: 
               
               
                   
                   
                   
                 Maintain user information that 
               
               
                   
                   
                   
                 contains the user&#39;s service 
               
               
                   
                   
                   
                 “type”, e.g. real-time versus 
               
               
                   
                   
                   
                 XML DD Market Data 
               
               
                   
                   
                   
                 Match data delivery timing to 
               
               
                   
                   
                   
                 service type as defined by XML 
               
               
                   
                   
                   
                 DD 
               
               
                   
               
             
          
         
       
     
         [0094]    Message Distribution Process 
         [0095]    Once the message for a subscriber (vendor, partner) is built, the message is delivered over a public or private network to the appropriate destination. After an acknowledgement is received from the destination, the next message is delivered. If there is a network disruption and the acknowledgment is not received, the message transfer is rolled back and then delivered when the connectivity is back up. 
         [0096]    According to an aspect of the distribution process of the present invention, each message can be delivered in real-time, globally, to any desired destination. For instance, messages from a content generator can be dynamically transformed, packaged, processed, and distributed all in real-time (e.g., as they are received), rather than being stored, and then retrieved at a later time for distribution to a particular subscriber. Further, the system allows setting a priority level to each message so that a better performance can be achieved by transferring the high priority messages first. In certain embodiments, messages are queued up at the source until a successful transmission is made, which ensures that no data is lost when the destination system is not available. Moreover, the messaging system allows reliability and audit-ability of the data sent because each message can have its own message ID and a correlation ID, which allows unique message transfer and associated statistical data, for instance, data regarding when the message was delivered. 
         [0097]    According to an aspect of the present invention, a custom and simple Document Type Definition (DTD) for the XML system is used. Each XML tag specified within the DTD for the XML Element Hierarchy, illustrated in  FIG. 10 , may be divided into subsections representing major DTD categories, such as: Message tags (common to all messages); Numeric tags (News &amp; Pricing data); Numeric tags (Analytics data); Textual tags; and Metadata tags (News &amp; Pricing and Analytics). The Element Hierarchy Diagram ( FIG. 10 ) is used to illustrate exemplary parent-child relationship of complex types. 
         [0098]    Table 3 provides tag names, the paths, as well as a description for each tag, including applicable rules. It also contains content data type, sample values (if appropriate), frequency of tag occurrence, its attributes, and sub-elements, if any. If the tag does not have any attributes or sub-elements, then those sections are excluded from the listing. The DTD Source is used only for complex tag types. 
         [0000]    
       
         
               
               
               
             
           
               
                 TABLE 3 
               
               
                   
               
               
                 Path 
                 Tag Name 
                 Description 
               
               
                   
               
             
             
               
                 Root element. 
                 &lt;message&gt; 
                 This is the root element of anXML message. It 
               
               
                   
                   
                 indicates the start and end of a message. 
               
               
                 &lt;message&gt; 
                 &lt;sendDt&gt; 
                 Tag indicating the date and time that of message 
               
               
                   
                   
                 distribution. The value from this tag should be used 
               
               
                   
                   
                 as the &lt;dataPoint&gt; dateTime attribute for storing 
               
               
                   
                   
                 numeric News &amp; Pricing messages. 
               
               
                 &lt;message&gt; 
                 &lt;sendTo&gt; 
                 Tag indicating partner distribution. 
               
               
                   
                 &lt;service&gt; 
                 Parent tag providing service “type” and release 
               
               
                   
                   
                 timing instruction related to underlying message. 
               
               
                   
                   
                 The “type” attribute identifies the specific delivery 
               
               
                   
                   
                 type, e.g. real-time versus end-of-day, while 
               
               
                   
                   
                 “releaseTime” provides the date and time that the 
               
               
                   
                   
                 message may be released to end-users. This is for 
               
               
                   
                   
                 Partners only. 
               
               
                 &lt;message&gt; 
                 &lt;dataPoint&gt; 
                 Contains the data point value and descriptive 
               
               
                 &lt;num&gt; 
                   
                 attributes. Required for &lt;num&gt; message types. It 
               
               
                   
                   
                 represents the price at a given point in time 
               
               
                   
                   
                 Identifies the message as numeric data (versus 
               
               
                   
                   
                 textual content). Used to update a time-series 
               
               
                   
                   
                 database of the referenced instrument (&lt;symbol&gt;). 
               
               
                 &lt;message&gt; 
                 &lt;author&gt; 
                 Specifies the name of the provider of the page 
               
               
                 &lt;page&gt; 
                   
                 content. 
               
               
                 &lt;message&gt; 
                 &lt;banner&gt; 
                 The name of the service the message is associated 
               
               
                 &lt;page&gt; 
                   
                 with. Part of the display in a properly formed page. 
               
               
                 &lt;message&gt; 
                 &lt;company&gt; 
                 A tag containing one or more codes representing 
               
               
                 &lt;page&gt; 
                   
                 specific entities or companies referenced in a page. 
               
               
                   
                   
                 Provides mechanism for filtering articles by 
               
               
                   
                   
                 company at the user interface. 
               
               
                 &lt;message&gt; 
                 &lt;cont&gt; 
                 The &lt;take&gt; and &lt;cont&gt; tags may be used together to 
               
               
                 &lt;page&gt; 
                   
                 distribute associated textual stories as a series of 
               
               
                   
                   
                 linked pages. The &lt;cont&gt; tag identifies a 
               
               
                   
                   
                 “continuation” page. Its page number reference uses 
               
               
                   
                   
                 the same &lt;cSource&gt; or &lt;cSource2&gt; value as the 
               
               
                   
                   
                 originating page. 
               
               
                 &lt;message&gt; 
                 &lt;cSource&gt; 
                 Contains the 3-letter service code that in 
               
               
                 &lt;page&gt; 
                   
                 combination with the &lt;pageNumber&gt; tag identifies 
               
               
                   
                   
                 a unique page of content. It is used for 
               
               
                   
                   
                 permissioning textual content. 
               
               
                 &lt;message&gt; 
                 &lt;cSource2&gt; 
                 Contains the 3-letter service code that in 
               
               
                 &lt;page&gt; 
                   
                 combination with the &lt;pageNumber&gt; tag identifies 
               
               
                   
                   
                 a unique page of content. Used only when multiple 
               
               
                   
                   
                 service codes are assigned to the underlying textual 
               
               
                   
                   
                 page transmission. It processes the associated page 
               
               
                   
                   
                 and store two (2) copies; one associated with 
               
               
                   
                   
                 &lt;cSource&gt; and one associated with &lt;cSource2&gt;. 
               
               
                   
                   
                 Each copy is treated as unique content for 
               
               
                   
                   
                 permissions and privileging purposes 
               
               
                 &lt;message&gt; 
                 &lt;date&gt; 
                 Indicates the date and time a textual page is 
               
               
                 &lt;page&gt; 
                   
                 published. YYYY-MM-DDThh:mm:ss.sTZD. 
               
               
                   
                   
                 hh = two digits of hour (00 through 23) (am/pm 
               
               
                   
                   
                 NOT allowed) 
               
               
                   
                   
                 mm = two digits of minute (00 through 59) 
               
               
                   
                   
                 ss = two digits of second (00 through 59) 
               
               
                   
                   
                 s = one or more digits representing a decimal 
               
               
                   
                   
                 fraction of a second 
               
               
                   
                   
                 TZD = time zone designator (Z or +hh:mm or − 
               
               
                   
                   
                 hh:mm) 
               
               
                 &lt;message&gt; 
                 &lt;dateLine&gt; 
                 The geographic location where the story originated. 
               
               
                 &lt;page&gt; 
               
               
                 &lt;message&gt; 
                 &lt;delete&gt; 
                 Indicates the page content is to be deleted. Deletes 
               
               
                 &lt;page&gt; 
                   
                 any previous instance of a page transmitted with the 
               
               
                   
                   
                 same &lt;sid&gt;, &lt;cSource&gt; and &lt;pageNumber&gt; values 
               
               
                   
                   
                 during a 24 hour period. 
               
               
                 &lt;message&gt; 
                 &lt;flash&gt; 
                 Identifies textual page content as a “News Flash”. 
               
               
                 &lt;page&gt; 
                   
                 News Flashes are used to communicate late 
               
               
                   
                   
                 breaking news or market events while the story is 
               
               
                   
                   
                 being developed. They typically do not contain a 
               
               
                   
                   
                 &lt;textBody&gt; tag. The system may (but is not 
               
               
                   
                   
                 required to) transmit the full story details (known as 
               
               
                   
                   
                 a “Flash Follow”), which. includes the &lt;textBody&gt; 
               
               
                   
                   
                 tag within one (1) hour of the News Flash message 
               
               
                   
                   
                 using the same story identification tag values. 
               
               
                 &lt;message&gt; 
                 &lt;headLine&gt; 
                 Required. Contains text used to foam the headline 
               
               
                 &lt;page&gt; 
                   
                 for a News Story, Flash or Flash Follow. 
               
               
                 &lt;message&gt; 
                 &lt;overWrite&gt; 
                 Tag instructing overwriting of a previously 
               
               
                 &lt;report&gt; &lt;page&gt; 
                   
                 distributed page. Overwrite any previous instance 
               
               
                   
                   
                 of a page transmitted with the same &lt;sid&gt;, 
               
               
                   
                   
                 &lt;cSource&gt; / &lt;cSource2&gt; and &lt;pageNumber&gt; 
               
               
                   
                   
                 values during a 24 hour period. 
               
               
                 &lt;message&gt; 
                 &lt;page&gt; 
                 Tag used for textual news stories. Identifies the start 
               
               
                   
                   
                 and end of the textual data for all news stories. It is 
               
               
                   
                   
                 not used for numeric market data or formatted data 
               
               
                 &lt;message&gt; 
                 &lt;pageNumber&gt; 
                 Tag used with &lt;cSource&gt; to define a specific textual 
               
               
                 &lt;page&gt; 
                   
                 page. These two tags are typically used to search for 
               
               
                   
                   
                 or recall pages of content at the user interface. 
               
               
                   
                   
                 Combining &lt;cSource&gt;, &lt;pageNumber&gt; and &lt;sid&gt; 
               
               
                   
                   
                 tags provides a mechanism for storing any version 
               
               
                   
                   
                 of a specific page. 
               
               
                 &lt;message&gt; 
                 &lt;pCategory&gt; 
                 Optional tag defining the category of page type that 
               
               
                 &lt;page&gt; 
                   
                 the underlying page belongs to 
               
               
                 &lt;message&gt; 
                 &lt;serviceCode&gt; 
                 Tag listing service or services to which the 
               
               
                 &lt;page&gt; 
                   
                 underlying textual message belongs. Used for 
               
               
                   
                   
                 textual content privileging and permissions purposes 
               
               
                   
                   
                 by the system and Partners. 
               
               
                 &lt;message&gt; 
                 &lt;sid&gt; 
                 Story Identifier. A unique seven-digit number 
               
               
                 &lt;page&gt; 
                   
                 assigned to every textual page transmission. This tag 
               
               
                   
                   
                 is critical for version control. 
               
               
                 &lt;message&gt; 
                 &lt;take&gt; 
                 The &lt;take&gt; and &lt;cont&gt; tags may be used in tandem 
               
               
                 &lt;page&gt; 
                   
                 to distribute a series of associated textual stories. 
               
               
                   
                   
                 The &lt;take&gt; tag contains the page sequence number 
               
               
                   
                   
                 within the series, followed by the page number that 
               
               
                   
                   
                 starts the series. 
               
               
                 &lt;message&gt; 
                 &lt;textBody&gt; 
                 Tag used to encapsulate the body text of any given 
               
               
                 &lt;page&gt; 
                   
                 textual page, e.g. contains the actual story. 
               
               
                   
                   
                 Although most updates include this tag, it is optional 
               
               
                   
                   
                 and applies solely to textual messages. 
               
               
                 &lt;message&gt; 
                 &lt;topic&gt; 
                 Tag that associates textual content with desired 
               
               
                 &lt;page&gt; 
                   
                 subject, category or group, e.g. specific geographical 
               
               
                   
                   
                 region and/or general subject or market. Used to 
               
               
                   
                   
                 filter content by desired “topic”. 
               
               
                 &lt;message&gt; 
                 &lt;conv&gt; 
                 Optional tag containing information for converting 
               
               
                 &lt;metaData&gt; 
                   
                 price values from one unit of measure to another) 
               
               
                 &lt;peimissionCode&gt; 
                   
                 based on commodity-specific characteristics such 
               
               
                 &lt;ewsSymbol&gt; 
                   
                 as specific gravity. 
               
               
                 &lt;message&gt; 
                 &lt;ewsSymbol&gt; 
                 Tag containing one symbol that is part of the parent 
               
               
                 &lt;metaData&gt; 
                   
                 permission code. Each permission code can have 
               
               
                 &lt;permissionCode&gt; 
                   
                 many ewsSymbol tags. 
               
               
                 &lt;message&gt; 
                 &lt;metaData&gt; 
                 Container for News &amp; Pricing metadata. 
               
               
                 &lt;message&gt; 
                 &lt;optAttr&gt; 
                 Optional tag containing descriptive attributes related 
               
               
                 &lt;metaData&gt; 
                   
                 to &lt;ewsSymbol&gt; such as commodity, location, 
               
               
                 &lt;permissionCode&gt; 
                   
                 delivery period, etc. 
               
               
                 &lt;ewsSymbol&gt; 
               
               
                 &lt;message&gt; 
                 &lt;permissionCode&gt; 
                 Two or three digit code that groups the News &amp; 
               
               
                 &lt;metaData&gt; 
                   
                 Pricing symbols together for permissioning 
               
               
                   
                   
                 Provisions and filters numeric messages by data 
               
               
                   
                   
                 category. 
               
               
                 &lt;message&gt; 
                 isoSymbol 
                 The unique identifier that represents a point of 
               
               
                 &lt;metadata&gt; 
                   
                 delivery and frequency type. 
               
               
                 &lt;permissionCode&gt; 
               
               
                 &lt;message&gt; 
                 &lt;metaData&gt; 
                 Container for Analytics metadata. 
               
               
                 &lt;message&gt; 
                 &lt;permissionCode&gt; 
                 This tag is for internal processing purposes. It is 
               
               
                 &lt;metadata&gt; 
                   
                 represented as a 2 or 3 digit code that groups the 
               
               
                   
                   
                 Analytics and News &amp; Pricing symbols. It is used to 
               
               
                   
                   
                 determine what content the customer will receive. 
               
               
                   
               
             
          
         
       
     
         [0099]    In accordance with another aspect of the invention, at least two types of messages (textual and numeric) can be received. The following are examples of transforming an input document, the process for tag mapping each type of message, and generated output documents. 
       Example 1 
     Textual 
       [0100]    An exemplary input document, for example, from the textual data queue, which can be processed in accordance with the present invention, is shown below: 
         [0000]    
       
         
               
             
           
               
                   
               
             
             
               
                 &lt;?xml version=“1.0” encoding=“UTF-8”?&gt; 
               
               
                 &lt;!DOCTYPE MESSAGE [ 
               
               
                 &lt;!-- this document is not valid --&gt; 
               
               
                 ]&gt; 
               
               
                 &lt;MESSAGE&gt; 
               
               
                  &lt;SEND_DT&gt;20100611 01:03:54&lt;/SEND_DT&gt; 
               
               
                  &lt;REPORT&gt; 
               
               
                  &lt;PRIORITY&gt;1&lt;/PRIORITY&gt; 
               
               
                  &lt;SOURCE&gt; 
               
               
                   &lt;EW&gt; 
               
               
                    &lt;SERVER&gt;sgcplew&lt;/SERVER&gt; 
               
               
                    &lt;DBREPLICA&gt;852566ad0056a9ec&lt;/DBREPLICA&gt; 
               
               
                    &lt;UNID&gt;186263C390C06BF88525773F001BCC1F&lt;/UNID&gt; 
               
               
                   &lt;/EW&gt; 
               
               
                  &lt;/SOURCE&gt; 
               
               
                  &lt;DESTINATION VENDOR=“BLOOMBERG” FORMAT=“PLATTS”&gt; 
               
               
                   &lt;IDENTIFIER&gt;01&lt;/IDENTIFIER&gt; 
               
               
                   &lt;FEEDBANNER&gt;--Platts Global Alert--&lt;/FEEDBANNER&gt; 
               
               
                  &lt;/DESTINATION&gt; 
               
               
                  &lt;DESTINATION VENDOR=“COMSTOCK” FORMAT=“COMSTOCK”&gt; 
               
               
                   &lt;FEEDBANNER&gt;--Platts Global Alert--&lt;/FEEDBANNER&gt; 
               
               
                   &lt;FEEDTOPIC&gt;ML,OPC,QA,PET,N,QQ,PET,PROD,PLTN&lt;/FEEDTOPIC&gt; 
               
               
                  &lt;/DESTINATION&gt; 
               
               
                  &lt;DESTINATION VENDOR=“TELERATE” FORMAT=“PLATTS”&gt; 
               
               
                   &lt;IDENTIFIER&gt;01&lt;/IDENTIFIER&gt; 
               
               
                   &lt;FEEDBANNER&gt;--Platts Global Alert--&lt;/FEEDBANNER&gt; 
               
               
                   &lt;FEEDTOPIC /&gt; 
               
               
                  &lt;/DESTINATION&gt; 
               
               
                  &lt;DESTINATION VENDOR=“EMIS” FORMAT=“EMIS”&gt; 
               
               
                   &lt;FEEDBANNER&gt;--Platts Global Alert--&lt;/FEEDBANNER&gt; 
               
               
                  &lt;/DESTINATION&gt; 
               
               
                  &lt;DESTINATION VENDOR=“KR” FORMAT=“PLATTS”&gt; 
               
               
                   &lt;IDENTIFIER&gt;01&lt;/IDENTIFIER&gt; 
               
               
                   &lt;FEEDBANNER&gt;--Platts Global Alert--&lt;/FEEDBANNER&gt; 
               
               
                  &lt;/DESTINATION&gt; 
               
               
                  &lt;DESTINATION VENDOR=“NTM” FORMAT=“NTM”&gt; 
               
               
                   &lt;IDENTIFIER&gt;PL&lt;/IDENTIFIER&gt; 
               
               
                   &lt;FEEDTOPIC&gt;MEAST OPEC QA CRU PLTN CRU PROD PLTN&lt;/FEEDTOPIC&gt; 
               
               
                  &lt;/DESTINATION&gt; 
               
               
                  &lt;DESTINATION VENDOR=“PCN” FORMAT=“PLATTS”&gt; 
               
               
                   &lt;COMSTOCKEXCHANGE /&gt; 
               
               
                   &lt;FEEDBANNER&gt;--Platts Global Alert--&lt;/FEEDBANNER&gt; 
               
               
                   &lt;NOPAGENUMBER /&gt; 
               
               
                   &lt;PRODUCT&gt;PCN&lt;/PRODUCT&gt; 
               
               
                   &lt;FEEDTOPIC&gt;MEAST OPEC QA CRU N ENY PGA CRU PROD 
               
               
                 PLTN&lt;/FEEDTOPIC&gt; 
               
               
                  &lt;/DESTINATION&gt; 
               
               
                  &lt;PAGE&gt; 
               
               
                   &lt;HEADLINE&gt;109--Tender data: Tasweeq offers 4.8 mil barrels Aug Al-Shaheen 
               
               
                 crude&lt;/HEADLINE&gt; 
               
               
                   &lt;TEXT_BODY&gt;Singapore (Platts)--11Jun2010/103 am EDT/503 GMT 
               
               
                 Seller: Tasweeq 
               
               
                 Country: Qatar 
               
               
                 Specs &amp;amp; quantity: Eight cargoes of heavy sour Al-Shaheen crude, 
               
               
                     each 600,000 barrels 
               
               
                 Port: FSO Astro Canopus 
               
               
                 When: Loading Aug 1-2, Aug 3-4, Aug 7-8, Aug 9-10, Aug 16-17, Aug 21-22, 
               
               
                   Aug 22-23, 25-26 
               
               
                 Basis: Differential to front line Platts Dubai assessment 
               
               
                 Close: June 14, with validity until June 17 
               
               
                 Data from: Trade source 
               
               
                 Notes: Tasweeq last sold nine parcels of Al-Shaheen crude, each 600,000 
               
               
                 barrels, loading in July at discounts of about $1.00-1.20/barrel to Platts 
               
               
                 Dubai assessments. Buyers were said to be majors ExxonMobil, Japan&#39;s Nippon 
               
               
                 Oil and Thailand&#39;s PTT. 
               
               
                 --Wendy Cheong, wendy_cheong@platts.com&lt;/TEXT_BODY&gt; 
               
               
                   &lt;DATE&gt;20100611 01:03:54&lt;/DATE&gt; 
               
               
                   &lt;DATELINE&gt;Singapore&lt;/DATELINE&gt; 
               
               
                   &lt;AUTHOR&gt;wcheo&lt;/AUTHOR&gt; 
               
               
                   &lt;PAGEHEADER&gt;MH0109&lt;/PAGEHEADER&gt; 
               
               
                   &lt;BANNER&gt;--Platts Global Alert--&lt;/BANNER&gt; 
               
               
                   &lt;PAGEWIDTH&gt;78&lt;/PAGEWIDTH&gt; 
               
               
                   &lt;PAGEHEIGHT&gt;120&lt;/PAGEHEIGHT&gt; 
               
               
                   &lt;TOPIC&gt;MEAST OPEC QA CRUN ENY PGA CRU PROD PLTN&lt;/TOPIC&gt; 
               
               
                   &lt;SID&gt;7649836&lt;/SID&gt; 
               
               
                   &lt;CSOURCE&gt;PGA&lt;/CSOURCE&gt; 
               
               
                   &lt;CSOURCE2&gt;PPN&lt;/CSOURCE2&gt; 
               
               
                   &lt;MRIC&gt;PGA109&lt;/MRIC&gt; 
               
               
                   &lt;NATTRIB&gt;PLATTS&lt;/NATTRIB&gt; 
               
               
                   &lt;NPRODUCT&gt;PGA PGT&lt;/NPRODUCT&gt; 
               
               
                   &lt;NSTYLE&gt;3&lt;/NSTYLE&gt; 
               
               
                   &lt;PCATEGORY&gt;NW&lt;/PCATEGORY&gt; 
               
               
                  &lt;/PAGE&gt; 
               
               
                  &lt;/REPORT&gt; 
               
               
                 &lt;/MESSAGE&gt; 
               
               
                   
               
             
          
         
       
     
         [0101]    Upon receipt of a textual input message, such as the message above, by the message flow, the following processing may be performed: 
         [0102]    First, the message is propagated to a “Check Content Type” node, which, for example, may run the CheckEWSType message flow shown in  FIG. 4 . In this example, the message would be identified as “Textual” message based on the presence of the “PAGE” tag. 
         [0103]    The message is then routed to a “Build Textual Data” node, such as node  210  shown in  FIG. 2 . This node may verify that the message includes valid tags, check for any missing tags, and route the message to an error queue if there is a missing tag. If there are valid tags, a second check is then performed to verify the vendors who subscribe to this category of message. Each vendor has the permissions set up against the &lt;cSource&gt; tag. If there are no vendors who subscribe to the &lt;cSource&gt; tag in the incoming message, the message is sent to a no-subscription queue. If there are subscribing vendors, then individual messages are created from one input message to each individual vendor with a separate &lt;sendTo&gt; tag. 
         [0104]    All the incoming tags are not necessarily translated. However, the following tags may be picked up from the input message, and new tags may be added, such as the &lt;serviceType&gt; tag, which has been included to expand the data delivery options to more types of data in future using the same delivery mechanism: 
         [0000]    
       
         
               
               
             
           
               
                   
                   
               
             
             
               
                   
                 &lt;headLine&gt; 
               
               
                   
                 &lt;textBody&gt; 
               
               
                   
                 &lt;date&gt; 
               
               
                   
                 &lt;dateline&gt; 
               
               
                   
                 &lt;author&gt; 
               
               
                   
                 &lt;banner&gt; 
               
               
                   
                 &lt;topic&gt; 
               
               
                   
                 &lt;sid&gt; 
               
               
                   
                 &lt;pCategory&gt; 
               
               
                   
                   
               
             
          
         
       
     
         [0105]    After the message is built for each vendor, the message is propagated to a Vendor Destination node, such as node  216  in  FIG. 3 . From the Vendor Destination node the message is finally sent to the specific queue created for the vendor in the system. After completing the delivery, the message is sent to a second flow where the audit details are captured to report on performance and auditing information. 
         [0106]    An exemplary output document could be as follows: 
         [0000]    
       
         
               
             
           
               
                   
               
             
             
               
                 &lt;message&gt; 
               
               
                  &lt;sendTo&gt;BACKUP&lt;/sendTo&gt; 
               
               
                  &lt;sendDt&gt;2010-06-11T01:03:54-04:00&lt;/sendDt&gt; 
               
               
                  &lt;service type=“RealTime” 
               
               
                  releaseTime=“2010-06-11T01:03:54-04:00”/&gt; 
               
               
                  &lt;page&gt; 
               
               
                   &lt;headLine&gt;109--Tender data: Tasweeq offers 4.8 mil barrels Aug Al- 
               
               
                   Shaheen crude&lt;/headLine&gt; 
               
               
                   &lt;textBody&gt;Singapore (Platts)--11Jun2010/103 am EDT/503 GMT 
               
               
                   Seller: Tasweeq 
               
               
                   Country: Qatar 
               
               
                   Specs &amp;amp; quantity: Eight cargoes of heavy sour Al-Shaheen 
               
               
                    crude, each 600,000 barrels 
               
               
                   Port: FSO Astro Canopus 
               
               
                   When: Loading Aug 1-2, Aug 3-4, Aug 7-8, Aug 9-10, Aug 16-17, 
               
               
                   Aug 21-22, 
               
               
                    Aug 22-23, 25-26 
               
               
                   Basis: Differential to front line Platts Dubai assessment 
               
               
                   Close: June 14, with validity until June 17 
               
               
                   Data from: Trade source 
               
               
                   Notes: Tasweeq last sold nine parcels of Al-Shaheen crude, each 
               
               
                   600,000 barrels, loading in July at discounts of about $1.00-1.20/ 
               
               
                   barrel to Platts Dubai assessments. Buyers were said to be 
               
               
                   majors ExxonMobil, Japan&amp;apos;s Nippon 
               
               
                   Oil and Thailand&amp;apos;s PTT. 
               
               
                   --Wendy Cheong, wendy_cheong@platts.com&lt;/textBody&gt; 
               
               
                   &lt;date&gt;2010-06-11T01:03:54-04:00&lt;/date&gt; 
               
               
                   &lt;dateLine&gt;Singapore&lt;/dateLine&gt; 
               
               
                   &lt;author&gt;wcheo&lt;/author&gt; 
               
               
                   &lt;pageNumber&gt;0109&lt;/pageNumber&gt; 
               
               
                   &lt;banner&gt;--Platts Global Alert&lt;/banner&gt; 
               
               
                   &lt;topic&gt;ML,OPC,QA,PET,N,QQ,PET,PROD,PLTN&lt;/topic&gt; 
               
               
                   &lt;sid&gt;7649836&lt;/sid&gt; 
               
               
                   &lt;cSource&gt;PGA&lt;/cSource&gt; 
               
               
                   &lt;cSource2&gt;PPN&lt;/cSource2&gt; 
               
               
                   &lt;serviceCode&gt;PPN&lt;/serviceCode&gt; 
               
               
                   &lt;pCategory&gt;NW&lt;/pCategory&gt; 
               
               
                  &lt;/page&gt; 
               
               
                 &lt;/message&gt; 
               
               
                   
               
             
          
         
       
     
       Example 2 
     Numeric 
       [0107]    An exemplary input document, for example, from the numeric data queue, which can be processed in accordance with the present invention, is shown below: 
         [0108]    Input Document: 
         [0000]    
       
         
               
             
           
               
                   
               
             
             
               
                 &lt;?xml version=“1.0” encoding=“UTF-8”?&gt; 
               
               
                 &lt;!DOCTYPE MESSAGE [&lt;!-- this document is not valid --&gt;]&gt; 
               
               
                 &lt;MESSAGE&gt; 
               
               
                  &lt;SEND_DT&gt;20100611 01:46:35&lt;/SEND_DT&gt; 
               
               
                  &lt;REPORT&gt; 
               
               
                  &lt;PRIORITY&gt;2&lt;/PRIORITY&gt; 
               
               
                  &lt;SOURCE&gt; 
               
               
                   &lt;EW&gt; 
               
               
                    &lt;SERVER&gt;NYWPLSA&lt;/SERVER&gt; 
               
               
                    &lt;DBREPLICA&gt;85256738005038EC&lt;/DBREPLICA&gt; 
               
               
                    &lt;UNID&gt;5C4D52536CD3BD838525773F001FBB12&lt;/UNID&gt; 
               
               
                   &lt;/EW&gt; 
               
               
                  &lt;/SOURCE&gt; 
               
               
                  &lt;DESTINATION VENDOR=“COMSTOCK” FORMAT=“COMSTOCK” /&gt; 
               
               
                  &lt;DESTINATION VENDOR=“EMIS” FORMAT=“EMIS” /&gt; 
               
               
                  &lt;DESTINATION VENDOR=“KR” FORMAT=“PLATTS” /&gt; 
               
               
                  &lt;DESTINATION VENDOR=“BLOOMBERG” FORMAT=“PLATTS” /&gt; 
               
               
                  &lt;DESTINATION VENDOR=“TELERATE” FORMAT=“PLATTS” /&gt; 
               
               
                  &lt;DESTINATION VENDOR=“MARKETLINK” FORMAT=“MARKETLINK” /&gt; 
               
               
                  &lt;NUM&gt; 
               
               
                   &lt;PRICEPOINT&gt; 
               
               
                    &lt;DATETIME&gt;20100611 00:00:00&lt;/DATETIME&gt; 
               
               
                    &lt;BATE&gt;u&lt;/BATE&gt; 
               
               
                    &lt;PRICE&gt;690&lt;/PRICE&gt; 
               
               
                    &lt;SYMBOL VENDORLIST=“COMSTOCK, KR, BLOOMBERG”&gt;PDB03Dc 
               
               
                 19bCBDAA00DW2&lt;/SYMBOL&gt; 
               
               
                    &lt;SYMBOL VENDORLIST=“MARKETLINK”&gt;CBDAA00 860&lt;/SYMBOL&gt; 
               
               
                    &lt;xmlFeedOnly&gt; 
               
               
                     &lt;xmlVendor&gt;COMSTOCK, KR, BLOOMBERG, 
               
               
                 MARKETLINK&lt;/xmlVendor&gt; 
               
               
                     &lt;dataPoint symbol=“CBDAA00” cSymbol=“PDB03Dc 19bCBDAA00DW2” 
               
               
                 rSymbol=“CBDAA00 860” permissionCode=“BA” dateTime=“2010-06-11T00:00:00” 
               
               
                 bate=“u” trans=“N”&gt; 
               
               
                 690.00 
               
               
                 &lt;/dataPoint&gt; 
               
               
                     &lt;dtTzInfo TZ=“EST” /&gt; 
               
               
                    &lt;/xmlFeedOnly&gt; 
               
               
                   &lt;/PRICEPOINT&gt; 
               
               
                   &lt;PRICEPOINT&gt; 
               
               
                    &lt;DATETIME&gt;20100611 00:00:00&lt;/DATETIME&gt; 
               
               
                    &lt;BATE&gt;u&lt;/BATE&gt; 
               
               
                    &lt;PRICE&gt;690&lt;/PRICE&gt; 
               
               
                    &lt;SYMBOL VENDORLIST=“COMSTOCK, KR, BLOOMBERG”&gt;PDB03Dc 
               
               
                 19bCBDAB00DW2&lt;/SYMBOL&gt; 
               
               
                    &lt;SYMBOL VENDORLIST=“MARKETLINK”&gt;CBDAB00 860&lt;/SYMBOL&gt; 
               
               
                    &lt;xmlFeedOnly&gt; 
               
               
                     &lt;xmlVendor&gt;COMSTOCK, KR, BLOOMBERG, 
               
               
                 MARKETLINK&lt;/xmlVendor&gt; 
               
               
                     &lt;dataPoint symbol=“CBDAB00” cSymbol=“PDB03Dc 19bCBDAB00DW2” 
               
               
                 rSymbol=“CBDAB00 860” permissionCode=“BA” dateTime=“2010-06-11T00:00:00” 
               
               
                 bate=“u” trans=“N”&gt; 
               
               
                 690.00 
               
               
                 &lt;/dataPoint&gt; 
               
               
                     &lt;dtTzInfo TZ=“EST” /&gt; 
               
               
                    &lt;/xmlFeedOnly&gt; 
               
               
                   &lt;/PRICEPOINT&gt; 
               
               
                   &lt;PRICEPOINT&gt; 
               
               
                    &lt;DATETIME&gt;20100611 00:00:00&lt;DATETIME&gt; 
               
               
                    &lt;BATE&gt;u&lt;/BATE&gt; 
               
               
                    &lt;PRICE&gt;705&lt;/PRICE&gt; 
               
               
                    &lt;SYMBOL VENDORLIST=“COMSTOCK, KR, BLOOMBERG” &gt;PDB03Dc 
               
               
                 19bCBGAK00DW2&lt;/SYMBOL&gt; 
               
               
                    &lt;SYMBOL VENDORLIST=“MARKETLINK”&gt;CBGAK00 860&lt;/SYMBOL&gt; 
               
               
                    &lt;xmlFeedOnly&gt; 
               
               
                     &lt;xmlVendor&gt;COMSTOCK, KR, BLOOMBERG, 
               
               
                 MARKETLINK&lt;/xmlVendor&gt; 
               
               
                     &lt;dataPoint symbol=“CBGAK00” cSymbol=“PDB03Dc 19bCBGAK00DW2” 
               
               
                 rSymbol=“CBGAK00 860” permissionCode=“BA” dateTime=“2010-06-11T00:00:00” 
               
               
                 bate=“u” trans=“N”&gt; 
               
               
                 705.00 
               
               
                 &lt;/dataPoint&gt; 
               
               
                     &lt;dtTzInfo TZ=“EST” /&gt; 
               
               
                    &lt;/xmlFeedOnly&gt; 
               
               
                   &lt;/PRICEPOINT&gt; 
               
               
                   &lt;PRICEPOINT&gt; 
               
               
                    &lt;DATETIME&gt;20100611 00:00:00&lt;/DATETIME&gt; 
               
               
                    &lt;BATE&gt;u&lt;/BATE&gt; 
               
               
                    &lt;PRICE&gt;705&lt;/PRICE&gt; 
               
               
                    &lt;SYMBOL VENDORLIST=“COMSTOCK, KR, BLOOMBERG”&gt;PDB03Dc 
               
               
                 19bCBGAL00DW2&lt;/SYMBOL&gt; 
               
               
                    &lt;SYMBOL VENDORLIST=“MARKETLINK”&gt;CBGAL00 860&lt;/SYMBOL&gt; 
               
               
                    &lt;xmlFeedOnly&gt; 
               
               
                     &lt;xmlVendor&gt;COMSTOCK, KR, BLOOMBERG, 
               
               
                 MARKETLINK&lt;/xmlVendor&gt; 
               
               
                     &lt;dataPoint symbol=“CBGAL00” cSymbol=“PDB03Dc 19bCBGAL00DW2” 
               
               
                 rSymbol=“CBGAL00 860” permissionCode=“BA” dateTime=“2010-06-11T00:00:00” 
               
               
                 bate=“u” trans=“N”&gt; 
               
               
                 705.00 
               
               
                 &lt;/dataPoint&gt; 
               
               
                     &lt;dtTzInfo TZ=“EST” /&gt; 
               
               
                    &lt;/xmlFeedOnly&gt; 
               
               
                   &lt;/PRICEPOINT&gt; 
               
               
                   &lt;PRICEPOINT&gt; 
               
               
                    &lt;DATETIME&gt;20100611 00:00:00&lt;/DATETIME&gt; 
               
               
                    &lt;BATE&gt;u&lt;/BATE&gt; 
               
               
                    &lt;PRICE&gt;569&lt;/PRICE&gt; 
               
               
                    &lt;SYMBOL VENDORLIST=“COMSTOCK, KR, BLOOMBERG”&gt;PDB03Dc 
               
               
                 19bCB3BA00DW2&lt;/SYMBOL&gt; 
               
               
                    &lt;SYMBOL VENDORLIST=“MARKETLINK”&gt;CB3BA00 860&lt;/SYMBOL&gt; 
               
               
                    &lt;xmlFeedOnly&gt; 
               
               
                     &lt;xmlVendor&gt;COMSTOCK, KR, BLOOMBERG, 
               
               
                 MARKETLINK&lt;/xmlVendor&gt; 
               
               
                     &lt;dataPoint symbol=“CB3BA00” cSymbol=“PDB03Dc 19bCB3BA00DW2” 
               
               
                 rSymbol=“CB3BA00 860” permissionCode=“BA” dateTime=“2010-06-11T00:00:00” 
               
               
                 bate=“u” trans=“N”&gt; 
               
               
                 569.00 
               
               
                 &lt;/dataPoint&gt; 
               
               
                     &lt;dtTzInfo TZ=“EST” /&gt; 
               
               
                    &lt;/xmlFeedOnly&gt; 
               
               
                   &lt;/PRICEPOINT&gt; 
               
               
                   &lt;PRICEPOINT&gt; 
               
               
                    &lt;DATETIME&gt;20100611 00:00:00&lt;/DATETIME&gt; 
               
               
                    &lt;BATE&gt;u&lt;/BATE&gt; 
               
               
                    &lt;PRICE&gt;569&lt;/PRICE&gt; 
               
               
                    &lt;SYMBOL VENDORLIST=“COMSTOCK, KR, BLOOMBERG”&gt;PDB03Dc 
               
               
                 19bCB3BB00DW2&lt;/SYMBOL&gt; 
               
               
                    &lt;SYMBOL VENDORLIST=“MARKETLINK”&gt;CB3BB00 860&lt;/SYMBOL&gt; 
               
               
                    &lt;xmlFeedOnly&gt; 
               
               
                     &lt;xmlVendor&gt;COMSTOCK, KR, BLOOMBERG, 
               
               
                 MARKETLINK&lt;/xmlVendor&gt; 
               
               
                     &lt;dataPoint symbol=“CB3BB00” cSymbol=“PDB03Dc 19bCB3BB00DW2” 
               
               
                 rSymbol=“CB3BB00 860” permissionCode=“BA” dateTime=“2010-06-11T00:00:00” 
               
               
                 bate=“u” trans=“N”&gt; 
               
               
                 569.00 
               
               
                 &lt;/dataPoint&gt; 
               
               
                     &lt;dtTzInfo TZ=“EST” /&gt; 
               
               
                    &lt;/xmlFeedOnly&gt; 
               
               
                   &lt;/PRICEPOINT&gt; 
               
               
                   &lt;PRICEPOINT&gt; 
               
               
                    &lt;DATETIME&gt;20100611 00:00:00&lt;/DATETIME&gt; 
               
               
                    &lt;BATE&gt;u&lt;/BATE&gt; 
               
               
                    &lt;PRICE&gt;516&lt;/PRICE&gt; 
               
               
                    &lt;SYMBOL VENDORLIST=“COMSTOCK, KR, BLOOMBERG”&gt;PDB03Dc 
               
               
                 19bCB8BA00DW2&lt;SYMBOL&gt; 
               
               
                    &lt;SYMBOL VENDORLIST=“MARKETLINK”&gt;CB8BA00 860&lt;/SYMBOL&gt; 
               
               
                    &lt;xmlFeedOnly&gt; 
               
               
                     &lt;xmlVendor&gt;COMSTOCK, KR, BLOOMBERG, 
               
               
                 MARKETLINK&lt;/xmlVendor&gt; 
               
               
                     &lt;dataPoint symbol=“CB8BA00” cSymbol=“PDB03Dc 19bCB8BA00DW2” 
               
               
                 rSymbol=“CB8BA00 860” permissionCode=“BA” dateTime=“2010-06-11T00:00:00” 
               
               
                 bate=“u” trans=“N”&gt; 
               
               
                 516.00 
               
               
                 &lt;/dataPoint&gt; 
               
               
                     &lt;dtTzInfo TZ=“EST” /&gt; 
               
               
                    &lt;/xmlFeedOnly&gt; 
               
               
                   &lt;/PRICEPOINT&gt; 
               
               
                   &lt;PRICEPOINT&gt; 
               
               
                    &lt;DATETIME&gt;20100611 00:00:00&lt;/DATETIME&gt; 
               
               
                    &lt;BATE&gt;u&lt;/BATE&gt; 
               
               
                    &lt;PRICE&gt;516&lt;/PRICE&gt; 
               
               
                    &lt;SYMBOL VENDORLIST=“COMSTOCK, KR, BLOOMBERG”&gt;PDB03Dc 
               
               
                 19bCB8BB00DW2&lt;/SYMBOL&gt; 
               
               
                    &lt;SYMBOL VENDORLIST=“MARKETLINK”&gt;CB8BB00 860&lt;/SYMBOL&gt; 
               
               
                    &lt;xmlFeedOnly&gt; 
               
               
                     &lt;xmlVendor&gt;COMSTOCK, KR, BLOOMBERG, 
               
               
                 MARKETLINK&lt;/xmlVendor&gt; 
               
               
                     &lt;dataPoint symbol=“CB8BB00” cSymbol=“PDB03Dc 19bCB8BB00DW2” 
               
               
                 rSymbol=“CB8BB00 860” permissionCode=“BA” dateTime=“2010-06-11T00:00:00” 
               
               
                 bate=“u” trans=“N”&gt; 
               
               
                 516.00 
               
               
                 &lt;/dataPoint&gt; 
               
               
                     &lt;dtTzInfo TZ=“EST” /&gt; 
               
               
                    &lt;/xmlFeedOnly&gt; 
               
               
                   &lt;/PRICEPOINT&gt; 
               
               
                   &lt;PRICEPOINT&gt; 
               
               
                    &lt;DATETIME&gt;20100611 00:00:00&lt;/DATETIME&gt; 
               
               
                    &lt;BATE&gt;u&lt;/BATE&gt; 
               
               
                    &lt;PRICE&gt;480&lt;/PRICE&gt; 
               
               
                    &lt;SYMBOL VENDORLIST=“COMSTOCK, KR, BLOOMBERG”&gt;PDB03Dc 
               
               
                 19bCB1AK00DW2&lt;/SYMBOL&gt; 
               
               
                    &lt;SYMBOL VENDORLIST=“MARKETLINK”&gt;CB1AK00 860&lt;/SYMBOL&gt; 
               
               
                    &lt;xmlFeedOnly&gt; 
               
               
                     &lt;xmlVendor&gt;COMSTOCK, KR, BLOOMBERG, 
               
               
                 MARKETLINK&lt;/xmlVendor&gt; 
               
               
                     &lt;dataPoint symbol=“CB1AK00” cSymbol=“PDB03Dc 19bCB1AK00DW2” 
               
               
                 rSymbol=“CB1AK00 860” permissionCode=“BA” dateTime=“2010-06-11T00:00:00” 
               
               
                 bate=“u” trans=“N”&gt; 
               
               
                 480.00 
               
               
                 &lt;/dataPoint&gt; 
               
               
                     &lt;dtTzInfo TZ=“EST” /&gt; 
               
               
                    &lt;/xmlFeedOnly&gt; 
               
               
                   &lt;/PRICEPOINT&gt; 
               
               
                   &lt;PRICEPOINT&gt; 
               
               
                    &lt;DATETIME&gt;20100611 00:00:00&lt;/DATETIME&gt; 
               
               
                    &lt;BATE&gt;u&lt;/BATE&gt; 
               
               
                    &lt;PRICE&gt;480&lt;/PRICE&gt; 
               
               
                    &lt;SYMBOL VENDORLIST=“COMSTOCK, KR, BLOOMBERG”&gt;PDB03Dc 
               
               
                 19bCB1AL00DW2&lt;/SYMBOL&gt; 
               
               
                    &lt;SYMBOL VENDORLIST=“MARKETLINK”&gt;CB1AL00 860&lt;/SYMBOL&gt; 
               
               
                    &lt;xmlFeedOnly&gt; 
               
               
                     &lt;xmlVendor&gt;COMSTOCK, KR, BLOOMBERG, 
               
               
                 MARKETLINK&lt;/xmlVendor&gt; 
               
               
                     &lt;dataPoint symbol=“CB1AL00” cSymbol=“PDB03Dc 19bCB1AL00DW2” 
               
               
                 rSymbol=“CB1AL00 860” permissionCode=“BA” dateTime=“2010-06-11T00:00:00” 
               
               
                 bate=“u” trans=“N”&gt; 
               
               
                 480.00 
               
               
                 &lt;/dataPoint&gt; 
               
               
                     &lt;dtTzInfo TZ=“EST” /&gt; 
               
               
                    &lt;/xmlFeedOnly&gt; 
               
               
                   &lt;/PRICEPOINT&gt; 
               
               
                   &lt;PRICEPOINT&gt; 
               
               
                    &lt;DATETIME&gt;20100611 00:00:00&lt;/DATETIME&gt; 
               
               
                    &lt;BATE&gt;u&lt;/BATE&gt; 
               
               
                    &lt;PRICE&gt;480&lt;/PRICE&gt; 
               
               
                    &lt;SYMBOL VENDORLIST=“COMSTOCK, KR, BLOOMBERG”&gt;PDB03Dc 
               
               
                 19bCB3AJ00DW2&lt;SYMBOL&gt; 
               
               
                    &lt;SYMBOL VENDORLIST=“MARKETLINK”&gt;CB3AJ00 860&lt;/SYMBOL&gt; 
               
               
                    &lt;xmlFeedOnly&gt; 
               
               
                     &lt;xmlVendor&gt;COMSTOCK, KR, BLOOMBERG, 
               
               
                 MARKETLINK&lt;/xmlVendor&gt; 
               
               
                     &lt;dataPoint symbol=“CB3AJ00” cSymbol=“PDB03Dc 19bCB3AJ00DW2” 
               
               
                 rSymbol=“CB3AJ00 860” permissionCode=“BA” dateTime=“2010-06-11T00:00:00” 
               
               
                 bate=“u” trans=“N”&gt; 
               
               
                 480.00 
               
               
                 &lt;/dataPoint&gt; 
               
               
                     &lt;dtTzInfo TZ=“EST” /&gt; 
               
               
                    &lt;/xmlFeedOnly&gt; 
               
               
                   &lt;/PRICEPOINT&gt; 
               
               
                   &lt;PRICEPOINT&gt; 
               
               
                    &lt;DATETIME&gt;20100611 00:00:00&lt;/DATETIME&gt; 
               
               
                    &lt;BATE&gt;u&lt;/BATE&gt; 
               
               
                    &lt;PRICE&gt;477&lt;/PRICE&gt; 
               
               
                    &lt;SYMBOL VENDORLIST=“COMSTOCK, KR, BLOOMBERG”&gt;PDB03Dc 
               
               
                 19bCB3AK00DW2&lt;SYMBOL&gt; 
               
               
                    &lt;SYMBOL VENDORLIST=“MARKETLINK”&gt;CB3AK00 860&lt;/SYMBOL&gt; 
               
               
                    &lt;xmlFeedOnly&gt; 
               
               
                     &lt;xmlVendor&gt;COMSTOCK, KR, BLOOMBERG, 
               
               
                    MARKETLINK&lt;/xmlVendor&gt; 
               
               
                     &lt;dataPoint symbol=“CB3AK00” cSymbol=“PDB03Dc 19bCB3AK00DW2” 
               
               
                     rSymbol=“CB3AK00 860” permissionCode=“BA” dateTime=“2010-06- 
               
               
                     11T00:00:00” bate=“u” trans=“N”&gt;477.00&lt;/dataPoint&gt; 
               
               
                     &lt;dtTzInfo TZ=“EST” /&gt; 
               
               
                    &lt;/xmlFeedOnly&gt; 
               
               
                   &lt;/PRICEPOINT&gt; 
               
               
                  &lt;/NUM&gt; 
               
               
                  &lt;/REPORT&gt; 
               
               
                 &lt;/MESSAGE&gt; 
               
               
                   
               
             
          
         
       
     
         [0109]    Upon receipt of a numeric input message, such as that above, by the message flow, the following processing is performed: 
         [0110]    First, the message is propagated to a “Check Content Type” node, which, for example, may run the CheckEWSType message flow shown in  FIG. 4 . In this example, the message would be identified as a “Price 1 ” message based on the presence of the NUM tag. 
         [0111]    The message is then routed a “Check Pricing errors” node, such as node  208  of  FIG. 2 . This node verifies the valid tags and checks for any missing tags and routes it to error queue if there is a missing tag. This node checks the message for errors, missing mandatory information (Symbol, DataPoint, PermCode, DateTime, Date, Trans Attributes), and invalid permission codes. Assuming there are valid tags, a further check is performed to verify the vendors who subscribe to this dispatch category of message. Each vendor has the permissions set up against the permissionCode tag. 
         [0112]    If there are no vendors who subscribe to the permissionCode tag in the incoming message, the message is sent to a no-subscription queue. If there are subscribing vendors, then individual messages are created from one input message to each individual vendor with a separate &lt;sendTo&gt; tag. 
         [0113]    All the incoming tags do not need to be translated; however, the following tags are picked up from the input message: &lt;dataPoint&gt; tag with symbol, dateTime, permCode, bate, and trans attributes. New tags may be added like the &lt;serviceType&gt;, &lt;releaseTime&gt;, and &lt;dispatchReleaseTime&gt;, which have been included to expand the data delivery options to more types of data in the future using the same delivery mechanism. 
         [0114]    After the message is built for each vendor, the message is propagated to a Vendor Destination node, such as node  216  of  FIG. 2 . From the Vendor Destination node the message is finally sent to the specific queue created for the vendor in the system. 
         [0115]    After completing the delivery, the message is sent to a second flow where the audit details are captured to report on performance and auditing information. 
         [0116]    Output Document: 
         [0000]    
       
         
               
             
           
               
                   
               
             
             
               
                 &lt;message&gt; 
               
               
                  &lt;sendTo&gt;BACKUP&lt;/sendTo&gt; 
               
               
                  &lt;sendDt&gt;2010-06-11T01:46:35-04:00&lt;/sendDt&gt; 
               
               
                  &lt;service type=“RealTime” 
               
               
                  releaseTime=“2010-06-11T01:46:35-04:00”/&gt; 
               
               
                  &lt;service type=“Dispatch” releaseTime=“2010-06-11T08:00:00-04:00”/&gt; 
               
               
                  &lt;num&gt; 
               
               
                   &lt;dataPoint symbol=“CBDAA00” permCode=“BA” dateTime=“2010- 
               
               
                   06-11T00:00:00-04:00” bate=“u” trans=“N”&gt;690.00&lt;/dataPoint&gt; 
               
               
                   &lt;dataPoint symbol=“CBDAB00” permCode=“BA” dateTime=“2010- 
               
               
                   06-11T00:00:00-04:00” bate=“u” trans=“N”&gt;690.00&lt;/dataPoint&gt; 
               
               
                   &lt;dataPoint symbol=“CBGAK00” permCode=“BA” dateTime=“2010- 
               
               
                   06-11T00:00:00-04:00” bate=“u” trans=“N”&gt;705.00&lt;/dataPoint&gt; 
               
               
                   &lt;dataPoint symbol=“CBGAL00” permCode=“BA” dateTime=“2010- 
               
               
                   06-11T00:00:00-04:00” bate=“u” trans=“N”&gt;705.00&lt;/dataPoint&gt; 
               
               
                   &lt;dataPoint symbol=“CB3BA00” permCode=“BA” dateTime=“2010- 
               
               
                   06-11T00:00:00-04:00” bate=“u” trans=“N”&gt;569.00&lt;/dataPoint&gt; 
               
               
                   &lt;dataPoint symbol=“CB3BB00” permCode=“BA” dateTime=“2010- 
               
               
                   06-11T00:00:00-04:00” bate=“u” trans=“N”&gt;569.00&lt;/dataPoint&gt; 
               
               
                   &lt;dataPoint symbol=“CB8BA00” permCode=“BA” dateTime=“2010- 
               
               
                   06-11T00:00:00-04:00” bate=“u” trans=“N”&gt;516.00&lt;/dataPoint&gt; 
               
               
                   &lt;dataPoint symbol=“CB8BB00” permCode=“BA” dateTime=“2010- 
               
               
                   06-11T00:00:00-04:00” bate=“u” trans=“N”&gt;516.00&lt;/dataPoint&gt; 
               
               
                   &lt;dataPoint symbol=“CB1AK00” permCode=“BA” dateTime=“2010- 
               
               
                   06-11T00:00:00-04:00” bate=“u” trans=“N”&gt;480.00&lt;/dataPoint&gt; 
               
               
                   &lt;dataPoint symbol=“CB1AL00” permCode=“BA” dateTime=“2010- 
               
               
                   06-11T00:00:00-04:00” bate=“u” trans=“N”&gt;480.00&lt;/dataPoint&gt; 
               
               
                   &lt;dataPoint symbol=“CB3AJ00” permCode=“BA” dateTime=“2010- 
               
               
                   06-11T00:00:00-04:00” bate=“u” trans=“N”&gt;480.00&lt;/dataPoint&gt; 
               
               
                   &lt;dataPoint symbol=“CB3AK00” permCode=“BA” dateTime=“2010- 
               
               
                   06-11T00:00:00-04:00” bate=“u” trans=“N”&gt;477.00&lt;/dataPoint&gt; 
               
               
                  &lt;/num&gt; 
               
               
                 &lt;/message&gt; 
               
               
                   
               
             
          
         
       
     
       Example 3 
     Flow Details 
       [0117]    Shown in  FIG. 15  is a logical network diagram of an exemplary content publication system according to an embodiment of the present invention. Various types of numeric and textual content are received by at least one Transform Publish Filter (TPF)  102 ,  106  from a Content Generation System  110  via a computer network, such as the internet. The TPFs  102 ,  106  transform and dynamically package the received data and publish it to at least one of a plurality of subscribers  150 ,  155 ,  160 ,  165  based on a set of permissioning rules and via a network, such as the internet. 
         [0118]    As shown in  FIG. 16 , textual and numeric data is generated in a Content Generation System  110  and delivered via a messaging protocol  115  to an XML document delivery system  100 , such as the input documents shown in the prior examples. In accordance with an embodiment of the present invention, the system includes a TPF  1040  that filters and packages the content for delivery to a plurality of subscribers. The XML delivery system  100  is implemented on a computerized messaging platform, such as IBM WebSphere Message Broker®. The XML delivery system  100  communicates with the Subscriber hosts  150 ,  155 ,  160 ,  165  using an IP based messaging protocol  115  such as IBM WebsSphere MQ®. The system may include one or more servers including a dedicated and/or virtual server having memory therein. 
         [0119]    According to an embodiment of the present invention and as illustrated in  FIG. 17 , textual and numeric data from the Content Generation System  110  are sent to the XML Data Feed queue  2050  on the TPF  1040 . Each Execution Group shown in  FIG. 17  contains named groupings of message flows in the XML delivery system  100 . In this example, a message flow may be understood as a sequence of nodes, i.e. processing steps, that run on the XML delivery system  100  when an input message is received. On the XML delivery system  100 , a node represents a set of actions that define a processing step. In this configuration, the delivery system  100  allows for multiple data types, such as XML textual messages  122 , XML price messages  124 , and XML metadata messages  126 , to be processed simultaneously and yet still maintain the correct sequential order. The message flows can process the multiple data types by filtering the incoming message types (see  FIGS. 10 ,  11 ,  12 ). 
         [0120]      FIG. 17  depicts the execution groups of an exemplary TPF engine  1040  according to an embodiment of the present invention. The execution groups include the EWS Execution Group  2000 , the EWS-Textual Execution Group  2100 , the EWS-Textual-Subscriber Execution Group  2120 , the EWS-Metadata Execution Group  2200 , the EWS-Numeric Execution Group  2300 , the EWS-Numeric-Subscriber Execution Group  2320 , and a Utility Execution Group  2500 . The execution groups may then route data to a no subscription node  2740 , subscribers XML 2.0 data node  2700 , and/or an error queue  2780 . 
         [0121]    The EWS Execution Group  2000  sorts the data from the XML Data Feed queue  205  by determining its type and routing it to the correct queue. First the message type is identified (i.e., textual, numeric, or metadata), then the message is routed to the corresponding node for that message type, with specific tags determining the fulfillment criteria. If there are any errors in the XML tag structure, the messages are sent to the error queue and no further processing is done. 
         [0122]    As shown in  FIG. 17 , The EWS Execution Group  2000  is the entry point for received messages, such as XML 1.0 messages produced by the Content Generation System  110 . A flow, ProcessEWSFeed.msgflow  300 , which is diagrammed in  FIG. 18 , is the primary message flow in the EWS Execution Group. The main function of the ProcessEWSFeed.msgflow  300  is to determine which type of XML 1.0 message (i.e., textual, numeric, or metadata) has been received, after which the message is sent to the respective message queue. According to an embodiment of the present invention, the messages may be processed in a series of nodes. For example, messages may be processed in fifteen nodes within the ProcessEWSFeed.msgflow  300  as follows: 
         [0123]    Node  1 . EWSFEED.QUEUE  310 —This is the input node where XML 1.0 messages are received from the Content Generation System  110 . 
         [0124]    Node  2 . FlowOrder  312 —This node determines which order to process incoming messages, based on, for instance, order of receipt, content, key-words, or specific tags in the incoming message. 
         [0125]    Node  3 . DistributeXML10Msg  320 —This node sends copies of XML 1.0 messages to XML 1.0 Subscribers. 
         [0126]    Node  4 . XML10_DestinationList  336 —This is an output node which acts as a destination list where XML 1.0 messages are sent from the DistributeXML10Msg node  320 . 
         [0127]    Node  5 . TryCatch  316 —This node processes exceptions, if any, occurring in the DistributeXML10Msg node  320 . 
         [0128]    Node  6 . XML10_Failure Trace  318 —This node logs exception messages related to XML 1.0 message processing to a log file, such as xml10-Failure-Tracelog  342 . 
         [0129]    Node  7 . CheckEWSType  314  (see also FIG.  4 )—This is a sub message flow which determines the type of XML 1.0 message and routes the message to the appropriate node. Textual messages, which may be determined by the presence of &lt;page&gt; tag, are routed to the EWSFEED.TEXTUALDATA.QUEUE  334 . Price messages, which may be determined by the presence of &lt;num&gt; tag, are checked for pricing errors and routed to EWSFEED.PRICEDATA.QUEUE  332 . Metadata messages are checked for metadata errors and routed to EWSFEED.METADATA.QUEUE  330 . 
         [0130]    Node  8 . EWSFEED.METADATA.QUEUE  330 —This is the output node to store metadata messages. 
         [0131]    Node  9 . EWSFEED.PRICEDATA.QUEUE  332 —This is the output node to store numeric messages. 
         [0132]    Node  10 . EWSFEED.TEXTUALDATA.QUEUE  334 —This is the output node to store textual messages. 
         [0133]    Node  11 . XML1 — 0.QUEUE.LIST  328 —This is the input queue to load the XML1 — 0.QUEUE.LIST  340  Subscriber list file to the database table XML1 — 0.QUEUES  342 . If the XML 1.0 Subscriber list needs to be updated, the feed file will be stored in this queue. 
         [0134]    Node  12 . InsertQueueNames  326 —This node parses the XML 1.0 Subscriber feed list  340  stored in the XML1 — 0.QUEUES queue  328  and inserts the data into the XML1 — 0.QUEUES database table  342 . 
         [0135]    Node  13 . Failure Trace  322 —This node logs failure messages to a file such as Failure-Trace.log  344 . 
         [0136]    Node  14 . Exception Trace  324 —This node logs exception messages to a file such as ews-Exception-Trace.log  346 . 
         [0137]    Node  15 . ERROR.QUEUE  338 —This is the output node to store failure messages. 
         [0138]    Textual messages, such as the input message shown above, are routed to a textual data queue. According to a further aspect of the present invention, as shown in  FIG. 19 , the EWS-Textual Execution Group  2100  processes the textual XML 1.0 messages within the TextualFlow.msgflow message flow  400 . The TextualFlow.msgflow message flow  400  receives XML 1.0 messages from the EWS Execution Group  2000 , and then converts them to XML 2.0 format. The XML 2.0 messages are then distributed to Subscriber queues  150 ,  155 ,  160 ,  165 . Within the TextualFlow.msgflow message flow  400 , messages can be processed in a series of nodes. For example, messages can be processed in sixteen nodes: 
         [0139]    Node  1 . EWSFEED.TEXTUALDATA.QUEUE  402 —This is the input node which receives textual XML 1.0 messages from the ProcessEWSFeed message flow  300 . 
         [0140]    Node  2 . FlowOrder  404 —This node determines the order in which incoming messages are processed. First a subscriber queue list, such as SubscriberQueueList file  434 , is loaded. If the SubscriberQueueList file  434  is null, the system builds the XML 2.0 messages and distributes them to the Subscriber queues. 
         [0141]    Node  3 . Filter  408 —This node checks whether the Subscriber queue list is null. 
         [0142]    Node  4 . EWS.SUBSCRIBER.INFLIGHT.QUEUE  410 —This node retrieves messages from EWS.SUBSCRIBER.INFLIGHT.QUEUE, which holds the Subscriber queue list in XML format. 
         [0143]    Node  5 . LoadSubscriberQueueList  412 —When the Subscriber queue list is null while processing a message, this node loads the Subscriber queue list. 
         [0144]    Node  6 . BuildTextualData  406 —This node transforms XML 1.0 messages to XML 2.0 messages and then sends the messages to the Subscriber processing queues. 
         [0145]    Node  7 . Subscriber Destination  424 —This is the output node, which sends transformed XML 2.0 messages to subscriber-specific sub-flow nodes. 
         [0146]    Node  8 . EnvFields  426 —This is a sub-flow node which saves environment fields. 
         [0147]    Node  9 . Failure Trace  414 —This node logs failure messages to a log file, such as ews-Textual-Failure-Trace.log  436 . 
         [0148]    Node  10 . Exception Trace  416 —This node logs exception messages to a log file, such as ews-Textual-Exception-Trace.log  438 . 
         [0149]    Node  11 . ERROR.QUEUE  430 —This node is the output queue, which is used to store error messages. 
         [0150]    Node  12 . NO.SUBSCRIPTION.QUEUE  428 —This node is an output queue used to store messages which have not been subscribed to by the Subscribers  150 ,  155 ,  160 ,  165 . 
         [0151]    Node  13 . ErrorHandler  432 —This is a sub flow node used to process errors. 
         [0152]    Node  14 . EWSFEED.TEXTUAL.CACHE.REFRESH  422 —This is the input node to refresh cache data. 
         [0153]    Node  15 . Cache Reset  418 —This node is responsible for resetting the cache. 
         [0154]    Node  16 . ErrorHandler 1   420 —This is an error handler sub message flow for processing errors. 
         [0155]    The EWS-Textual-Subscriber Execution Group  2120  contains subscriber-specific message flows for processing textual messages. According to an aspect of the present invention, there may be a plurality of subscriber specific message flows.  FIG. 20  shows an exemplary message flow to a specific subscriber, SubscriberProcessingSUBSCRIBER.msgflow  450 . This message flow receives XML 2.0 messages from the EWS-Textual message flow  400  and then applies subscriber-specific logic to the message flow, before distributing it to the Subscriber queue. Within the SubscriberProcessingSUBSCRIBER.msgflow  450 , messages may be processed in five nodes: 
         [0156]    Node  1 . MQInput  452 —This is an input node for processing textual messages from a specific Subscriber. 
         [0157]    Node  2 . SubscriberProcessingSubFlow  454 —This message sub-flow executes Subscriber-specific logic. 
         [0158]    Node  3 . MQOutput—This is the output node for a specific Subscriber. 
         [0159]    Node  4 . ERROR.QUEUE  460 —This is the output queue used to store error messages. 
         [0160]    Node  5 . EnvFields  458 —This is the message sub-flow used to populate environmental fields. 
         [0161]    Numeric messages, such as the input message shown above, are routed to a numeric data execution group, as shown in  FIG. 17 . According to a further aspect of the present invention, the Numeric Execution Group  2300  processes numeric XML 1.0 messages using the NumericFlow.msgflow  500  as shown in  FIG. 21 . The NumericFlow.msgflow  500  receives XML 1.0 messages from the Content Generation System  110  and then converts them to XML 2.0 format, where they can be distributed to the Subscriber queues. Within the NumericFlow.msgflow  500 , messages may be processed in thirteen nodes: 
         [0162]    Node  1 . EWSFEED.PRICEDATA.QUEUE  502 —This is the input node for numeric XML 1.0 messages which are received from ProcessEWSFeed.msgflow  300  ( FIG. 18 ). 
         [0163]    Node  2 . FlowOrder  504 —This node determines in which order to process the incoming messages, based on, for instance, order of receipt, content, key-words, or specific tags in the incoming message. 
         [0164]    Node  3 . BuildPriceData  506 —This node transforms XML 1.0 messages to XML 2.0 message and then sends them to the Subscriber processing queues. 
         [0165]    Node  4 . Subscriber Destination  508 —This is the output node which sends transformed XML 2.0 messages to the Subscriber queues. 
         [0166]    Node  5 . EnvFields  510 —This is a sub message flow which populates environment fields. 
         [0167]    Node  6 . Failure Trace  516 —This node logs failure messages to a log file such as ews-Numeric-Failure-Trace.log  528 . 
         [0168]    Node  7 . Exception Trace  520 —This node logs exception messages to a log file such as ews-Numeric-Exception-Trace.log  530 . 
         [0169]    Node  8 . ERROR.QUEUE  518 —This node is the output queue to store error messages. 
         [0170]    Node  9 . NO.SUBSCRIPTION.QUEUE  514 —This node is the output queue to store messages for which there are no Subscribers. 
         [0171]    Node  10 . ErrorHandler  512 —This is a sub message flow to process errors. 
         [0172]    Node  11 . EWSFEED.NUMERIC.CACHE.REFRESH  526 —This is an input node for refreshing the data cache. 
         [0173]    Node  12 . Cache Reset  522 —This node will reset the cache. 
         [0174]    Node  13 . ErrorHandler 1   524 —This is the error handler sub message flow for processing errors. 
         [0175]    According to an aspect of the present invention, there may be a plurality of subscriber specific message flows.  FIG. 22  shows an exemplary message flow to a specific subscriber, NumericSubscriberProcessingSUBSCRIBER.msgflow  550 . This message flow receives XML 2.0 messages from the NumericFlow.msgflow  500  and then applies subscriber-specific logic to the message flow, before distributing it to the Subscriber queue. Within the NumericSubscriberProcessingSUBSCRIBER.msgflow  550 , messages may be processed in five nodes: 
         [0176]    Node  1 . MQInput  552 —This is an input node for processing numeric messages from a specific Subscriber. 
         [0177]    Node  2 . NumericVendorProcessingSubFlow  554 —This message sub-flow executes Subscriber-specific logic, such that unique packages may be built for each subscriber. 
         [0178]    Node  3 . MQOutput  556 —This is the output node for a specific Subscriber. 
         [0179]    Node  4 . ERROR.QUEUE  560 —This is the output queue used to store error messages. 
         [0180]    Node  5 . EnvFields  558 —This is the message sub-flow used to populate environmental fields. 
         [0181]    As shown in  FIG. 23 , the EWS-Metadata Execution Group  2200  is responsible for processing metadata messages using the MetaDataFlow.msgflow message flow  600 . The MetaDataFlow.msgflow message flow  600  receives XML 2.0 messages as an input, converts them to metadata messages, and then periodically distributes them to Subscribers  150 ,  155 ,  160 ,  165 . For instance, metadata may be distributed on a weekly basis. Within the MetaDataFlow.msgflow  600 , messages may be processed in fourteen nodes: 
         [0182]    Node  1 . EWSFEED.METADATA.QUEUE  602 —This is the input node where metadata messages in XML 2.0 format are received from the ProcessEWSFeed.msgflow  300  ( FIG. 18 ). 
         [0183]    Node  2 . FlowOrder  604 —This node determines the order in which to process incoming messages, based on, for instance, order of receipt, content, key-words, or specific tags in the incoming message. 
         [0184]    Node  3 . CheckForMetaDataErrors  606 —This node checks for errors in the incoming XML messages. Messages with errors are sent to the ERROR.QUEUE  630 . 
         [0185]    Node  4 . ProcessMetaData  608 —This node transforms XML 2.0 messages to metadata messages and then sends them to the Subscriber processing queues. 
         [0186]    Node  5 . Subscriber Destination  610 —This is the output node which sends transformed XML 2.0 messages to the Subscriber queues. 
         [0187]    Node  6 . EnvFields  612 —This is a message sub-flow, which populates environment fields. 
         [0188]    Node  7 . Failure Trace  618 —This node logs failure messages to a log file, such as ews-MetaData-Failure-Trace.log  632 . 
         [0189]    Node  8 . Exception Trace  622 —This node logs exception messages to a log file, such as ews-MetaData-Exception-Trace.log  634 . 
         [0190]    Node  9 . ERROR.QUEUE  630 —This is the output queue for storing error messages. 
         [0191]    Node  10 . NO.SUBSCRIPTION.QUEUE  616 —This is the output queue for storing messages for which there are no Subscribers. 
         [0192]    Node  11 . ErrorHandler  614 —This is a sub message flow for processing errors. 
         [0193]    Node  12 . EWSFEED.METADATA.CACHE.REFRESH  628 —This is the input node for refreshing the data cache. 
         [0194]    Node  13 . Cache Reset  624 —This node resets the cache. 
         [0195]    Node  14 . ErrorHandler 1   626 —This is the error handler sub message flow for processing errors. 
         [0196]    According to another aspect of the present invention, the TPF further includes a Utility Execution Group  2500 , which is directed to managing partner or subscriber queues and permissioning, for example, as shown in  FIG. 17 . In this example, the Utility Execution group contains five message flows. 
         [0197]    The first is the LoadPartner2QueuesMapping.msgflow message flow  800 , shown in  FIG. 24 . The LoadPartner2QueuesMapping.msgflow  800  inserts the data from the PARTNER2QUEUES mapping file  814  into the PARTNER2QUEUES database table  816 . A sample of the PARTNER2QUEUES mapping file  814  is as follows: 
         [0000]                                            CSQUARE |CSQRP1           TICHINA |TICHINA                        
Within the LoadPartner2QueuesMapping.msgflow message flow  800  are six nodes:
 
         [0198]    Node  1 . PARTNER2QUEUES.FEED.QUEUE  802 —This node is the input node. 
         [0199]    Node  2 . Partner2QueuesFeed  804 —This node loads the data from the PARTNER2QUEUES mapping file  814  and inserts it into the PARTNER2QUEUES database table  816 . 
         [0200]    Node  3 . DestinationList  806 —This node writes to the EWSFEED.TEXTUAL.CACHE.REFRESH node  422 , shown in  FIG. 19 , to refresh the data cache. 
         [0201]    Node  4 . Failure Trace  808 —This node logs the failure messages to a file, such as ews-Failure-Trace.log  817 . 
         [0202]    Node  5 . Exception Trace  810 —This node logs the exception messages to a file, such as ews-Exception-Trace.log  818 . 
         [0203]    Node  6 . ERROR.QUEUE  812 —This is the output node for saving failure messages. 
         [0204]    The second message flow also within the Utility Execution Group  2500  is LoadPartnerFilteringMapping.msgflow, shown in  FIG. 25 . This flow inserts the data from the input file into the PARTNER_FILTERING database table  835 . A sample of the input file data is as follows: 
         [0000]                                            REUTERS | CORRECTION_TAG | SEND           BLOOMBERG | CORRECTION_TAG | SEND                        
Within the LoadPartnerFilteringMapping.msgflow message flow  820  are six nodes:
 
         [0205]    Node  1 . PARTNERFILTERING.FEED.QUEUE  822 —This is the input node, which receives the data from the input file. 
         [0206]    Node  2 . Partnerfiltering  824 —This node loads the data from the PARTNER_FILTERING mapping file  834  and inserts it into the PARTNER_FILTERING database table  835 . 
         [0207]    Node  3 . Destination List  826 —This node writes to EWSFEED.TEXTUAL.CACHE.REFRESH node  422 , shown in  FIG. 19 , to refresh the data cache. 
         [0208]    Node  4 . Failure Trace  828 —This node logs the failure messages to a file, such as ews-Failure-Trace.log  838 . 
         [0209]    Node  5 . Exception Trace  830 —This node logs the exception messages to a file, such as ews-Exception-Trace.log  839 . 
         [0210]    Node  6 . ERROR.QUEUE  832 —This is the output node for saving failure messages. 
         [0211]    The third message flow within the Utility Execution Group  2500  is Load Permission File message flow for example, as shown in  FIG. 6 . LoadPermissionFile.msgflow  840  inserts the data from the PERMISSIONS input file  857  into the PERMISSIONS database table  858 . 
         [0212]    A sample of the PERMISSIONS input file  857  data is as follows: 
         [0000]                                            EWS_ALL |BACKUP           AA |CSQRP1           AE |CSQRP1                        
Within the LoadPermissionFile.msgflow message flow  840  are six nodes:
 
         [0213]    Node  1 . PERMISSIONS.FEED.QUEUE  842 —This is the input node, which receives the data from the PERMISSIONS input file  857  file. 
         [0214]    Node  2 . BuildPermissionTags  848 —This node loads the data from the mapping file and inserts it into the PERMISSIONS database table  858 . 
         [0215]    Node  3 . DestinationList  850 —This node writes the permission data to EWSFEED.TEXTUAL.CACHE.REFRESH  422  ( FIG. 19 ), EWSFEED.NUMERIC.CACHE.REFRESH  526  ( FIG. 21 ), and EWSFEED.METADATA.CACHE.REFRESH  628  ( FIG. 23 ), thereby refreshing the data cache. 
         [0216]    Node  4 . Failure Trace  852 —This node logs the failure messages to a file, such as ews-Failure-Trace.log  855 . 
         [0217]    Node  5 . Exception Trace  854 —This node logs the exception messages to a file, such as ews-Exception-Trace.log  857 . 
         [0218]    Node  6 . ERROR.QUEUE  856 —This is the output node for saving failure messages. 
         [0219]    This flow may also include a filtering node  846 , which filters data received from input file  857  prior to uploading at node  848 . 
         [0220]    The fourth message flow within the Utility Execution Group  2500  is LoadSubscriberQMapping.msgflow  860 , shown in  FIG. 26 . This message flow inserts the data from a VendorQMapping input file  863  into the EWS.SUBSCRIBER.INFLIGHT.QUEUE  410 , shown in  FIG. 19 . A sample of the VendorQMapping input file  863  input file data is as follows: 
         [0000]                                            CSQUARE.VO.QL | CSQRP1           TICHINA.VO.QL | TICHINA                        
Within the Load VendorQMapping.msgflow message flow  860  are eight nodes:
 
         [0221]    Node  1 . VENDORQLIST.FEED.QUEUE  862 —This is the input node, which receives the data from the VendorQMapping input file  863  file. 
         [0222]    Node  2 . ValidateMsg  864 —This node validates the configuration of the input data format by checking whether it is in the correct format, for instance “VENDORQ|VENDOR.” 
         [0223]    Node  3 . ConstructMsg  868 —This message flow constructs the message with a Subscriber Tag, such as: 
         [0000]    
       
         
               
               
             
           
               
                   
                   
               
             
             
               
                   
                 &lt;subscriber&gt; 
               
               
                   
                 &lt;mqQName&gt;CSQUARE.VO.QL&lt;/mqQName&gt; 
               
               
                   
                  &lt;vendorName&gt;CSQRD1&lt;/vendorName&gt; 
               
               
                   
                 &lt;/vendor&gt; 
               
               
                   
                   
               
             
          
         
       
     
         [0224]    Node  4 . DestinationList  870 —This node writes to EWSFEED.TEXTUAL.CACHE.REFRESH node  422 , shown in  FIG. 19 , thereby refreshing the cache data. 
         [0225]    Node  5 . PurgeQueue  872 —The EWS.SUBSCRIBER.INFLIGHT.QUEUE queue is mapped to receive the constructed message. 
         [0226]    Node  6 . Failure Trace  874 —This node logs the failure messages to a file, such as ews-Failure-Trace.log  877 . 
         [0227]    Node  7 . Exception Trace  876 —This node logs the exception messages to a file, such as ews-Exception-Trace.log  879 . 
         [0228]    Node  8 . ERROR.QUEUE  878 —This is the output node for saving failure messages. 
         [0229]    This flow may also include an additional message flow control node,  866 . 
         [0230]    LoadXMLDDTimeZoneMapping.msgflow  880  is the fifth message flow contained within the Utility Execution Group  2500  and is shown in  FIG. 27 . This message flow inserts the data from the input file transfers into the XMLDD_TIMEZONE_MAPPING file  896 . A sample of the XMLDD_TIMEZONE_MAPPING input file  896  data is as follows: 
         [0000]                                            MST | US/Mountain           PST | US/Pacific           GMT | Etc/Zulu                        
Within the LoadXMLDDTimeZoneMapping.msgflow message flow  880  are seven nodes:
 
         [0231]    Node  1 . XMLDD.TIMEZONE.FEED.QUEUE  882 —This is the input node, which receives the data from the input mapping file. 
         [0232]    Node  2 . ValidateMsg  884 —This node validates the input data in the XMLDD_TIMEZONE_MAPPING input file  896  configuration file, and checks for invalid conditions, such as an empty file or invalid data format. 
         [0233]    Node  3 . Insert_TimeZone Values  886 —This node inserts data into the table XMLDD_TIMEZONE_MAPPING  898  and updates the log. 
         [0234]    Node  4 . DestinationList  888 —This node writes to EWSFEED.NUMERIC.CACHE.REFRESH node  526 , shown in  FIG. 21 , thereby refreshing the cache data. 
         [0235]    Node  5 . Failure Trace  890 —This node logs the failure messages to a file, such as ews-Failure-Trace.log  895 . 
         [0236]    Node  6 . Exception Trace  892 —This node logs the exception messages to a file, such as ews-Exception-Trace.log  897 . 
         [0237]    Node  7 . ERROR.QUEUE  894 —This is the output node for saving failure messages. 
         [0238]    Exemplary output messages in accordance with the above described example are shown in  FIGS. 28 and 29 .  FIG. 28  shows an exemplary Price Assessment output message, while  FIG. 29  shows an exemplary News Story output message. 
         [0239]    While the invention has been described in detail above, the invention is not intended to be limited to the specific embodiments as described. It is evident that those skilled in the art may now make numerous uses and modifications of and departures from the specific embodiments described herein without departing from the inventive concepts.