XML formatting

With the advent of the CDISC ODM model and the progression of the FDA s endorsement of the CDISC models, I believe that eventually all clinical trial data will likely be submitted to the FDA in ODM or a similar XML format. The XML-based ODM is already gaining acceptance within the pharmaceutical industry as a means of transferring clinical trial data. SAS provides two ways to produce ODM data files using either PROC CDISC or the XML LIBNAME engine. 

All modern relational databases include the ability to export tables as XML files. It is usually possible to apply an XSLT transformation to the data as part of the export procedure. In the interest of simplicity and compatibility across different databases, no special transformation was applied to the tables extracted from the New Brunswick till database. Therefore, after exporting data out of MS Access in a generic XML format, the first XSLT transformation involves restructuring the data to conform to a Geochemical Survey XML schema, developed at the GSC (Adcock 2009b). The second transformation produces a set of files which conform to the GML schema (OGC, 2007). KML shares many features with GML, and hence the third and final GML-to-KML transformation is very simple. 

In 2002, IUPAC initiated work in the development of terminology of a standard for analytical data. The standard format, XML, is intended to be universal for all types of analytical instrumentation, without permutations for different techniques. The XML format is designed to have information content of data defined in several layers. The most generic information is in the first layer, or core. More specific information about the instrumentation, sample details and experimental settings are stored in subsequent layers. The layers are defined as core, sample, technique, vendor, enterprise and user.29 The existence of a universal format will aid in the analysis of data from multiple sources, as well as in the archival and retrieval of data from historical processes. 

Introduction of a new data item into data stored in XML format is much easier. A new element or attribute can be introduced (possibly in a new namespace) without difficulty, provided that the processing code is written with this possibility in mind. Such software will not break after encountering an unknown element, and the processing of information containing this new element can be implemented in an appropriate time. 

CML is the best known of the XML notations for capture of structural data, but several other formats use XML-based syntax. The Protein Data Bank (PDB) (http // www.wwpdb.org/) is the single worldwide repository for macromolecular structure data. A representation of the Brookhaven PDB is available in an XML format called PDBML (Westbrook et al. 2005). PDBML provides a way to export structures and information about them from a relational database. Another database that offers... 

Introduction of XML formats was a very important step toward better intercomputer communication, but it is not a miraculous solution to all problems. Not every possible relation is easily expressed in XML (Wang et al. 2005), so specifications usually contain many implicit assumptions that are not properly formalized. The Resource Description Framework (RDF) provides a very powerful yet simple model for this formalization (Manola and Miller 2004). In this framework, any information is transformed to basic units called triplets that are combined to map the available information. This unifying mechanism can be used to express hierarchical vocabularies for domain knowledge description, as in RDF Schema (Brickley and Guha 2004) or its extension, Web Ontology Language (OWL) (Smith et al. 2004), both standardized by the W3C. 

XML has started the second decade of its official existence, and already in its early years it has deeply influenced many areas of information processing. Its promise for scientific information exchange is only slowly being fulfilled, but recent developments are very positive. XML formats are replacing their text predecessors, so an understanding of XML technologies is a must for anyone interested in data mining applications. 

Scientific XML formats are still rapidly evolving, and it will take some time before stability is reached, but this does not mean they are unusable today. XML already provides several advantages over its predecessors including the availability of tools that simplify conversion to newer versions of XML when necessary. 

The possibilities and application of the Semantic Web to chemistry were initially identified by Murray-Rust and Rzepa (1999, 2000 Rzepa and Murray-Rust 2001) and have been promoted in a number of papers since. The precondition to the Semantic Web, the maintenance of data within XML format, has become a reality, whereas the representation of the data within XML has been subject to evolution in the last few years. For example, the SVG format for holding graphics as XML was initially promising, but adoption never took off beyond a few examples. As Adobe is no longer developing and supporting the format, it can be regarded at present as an evolutionary dead end. 

PubChem provides examples of both sorts of Web service. To search PubChem for a particular chemical name, then, you can use the Entrez Programming Utilities (http //www.ncbi.nlm.nih.gov/books/bv.fcgi rid=coursework.chapter.eutils). Requests to these go via the URL and can be typed into a browser by hand. For more sophisticated requests, PubChem provides the Power User Gateway (http // pubchem.ncbi.nlm.nih.gov/pug/pughelp.html). This uses a complicated XML format for requests, much of which is there for job control for large batches. 

The published version of the PSI-MS XML data interchange format also gives access to tools which allow the user to both convert from mass spectrometry text formats to the PSI-MS XML format and to view and browse stored data in PSI-MS XML format (Pedrioli et al., 2004). 

Compilation of glycan structures from different databases translated using a standardized Glyco-CT XML format. 

After these activities, the project file is stored in the DMS, while its structural content (the realization of the extruder) is stored inside the PDW repository, together with additional information like domain model annotations and enrichments. Importing of information into the PDW is done via an XML format that is directly based on, and thus convertible into, the core ontology concepts. External resources need to be transformed into this format, based on the rules defined by derivations of the Core Ontology s Transformation concept, and implemented e.g. by XML stylesheet transformations (see Subsect. 4.1.5). 

To enable the exchange of work process models between WOMS and other software tools, two tool-independent output formats, a HTML format and a XML format, are supported. 

The specification of a simulation problem in CHEOPS is done by means of setup files in XML format which describe the structure of the flowsheet to be solved as well as variables of various types (scalars, vectors, time profiles, and distributions). The variables are classified into inputs, outputs, parameters, and states. Inputs and parameters should be specified by the user. The setup files define references to the models, their types and associated tools, and the type of simulation with a respective set of simulation options. 

CHEOPS obtains this setup file in XML format from ModKit-l-. Tool wrappers are started according to this XML file. The input files required for the modeling tools Aspen Plus and gPROMS are obtained from the model repository ROME. CHEOPS applies a sequential-modular simulation strategy implemented as a solver component because all tool wrappers are able to provide closed-form model representations. The iterative solution process invokes the model evaluation functionality of each model representation, which refers to the underljdng tool wrapper to invoke the native computation in the modeling tool the model originated from. Finally, the results of all stream variables are written to a Microsoft Excel table when the simulation has terminated. 

One approach to automate the way of electronically requesting information from other software systems is the concept of service requests, which are mechanisms to create definable requests for external data. Service requests are predefined by key users of the systems, whereas the end-user simply calls a wizard for one of the predefined service requests, fills out the data required by the external software, and sends it to the target software. The wizard application translates the request to XML format, which is typically understood by the SDK of external software. Results from a service request are automatically converted, parsed, and transferred to the inbox by use of configurable software agents. 

Mapping a set of metabolites from one species onto a pathway created with another species, would allow one to see which metabolites are identical and which are missing. A diagram template may also be used to create a default pathway. As mentioned before, each pathway keeps its own information about the position of metabolites, and each created pathway may serve as basis for a template. A pathway diagram needs to be printable and easily transferred to a report container, such as a document. Finally, a pathway diagram may be exported either as image or in XML format including the structure (connection tables) and connectivity information of the molecules. 

The specification is preferably documented in XML format and can be customized by the user or administrator of the system. The verification module reads the specification and creates the corresponding input user interface dynamically rather than using any hard-coded user dialogue. A dynamic user dialogue is created with a set of... 

The UID provides the ability to save a definition to a database or to a local file system in XML format. The basic key field types that have to be handled are numeric, alphanumeric, currency, date and time, dropdown lists, and checkbox fields. Each field type includes labels appearing as an edit box label, descriptions used as hint texts for the user, as well as a unique identifier for referencing the field. 

A number of formafs are available for data export. These formats include SDF, image, small image, SMILES, InChl, XML, and either text or binary ASN.l. The PubChem native archive data format is ASN.l all other formats are converted from the original ASN.l. The XML formatted data is exactly equivalent to the ASN.l in content. SDF format is the industry standard for conveyance of chemical sfructure information and is readily imported into a large number of chemistry programs. Unfortunately, the SDF format is unable to handle all aspects of the ASN.l data and may not contain all archived information. The PubChem ASN.l specification, XML schema, and a description of PubChem SDF sfrucfure dafa (SD) fags are all found on fhe PubChem FTP sife in the "specifications" directory. 

---