XML’s set of tools allows developers to create web pages - and much more. XML allows developers to set standards defining the information that should appear in a document, and in what sequence. XML, in combination with other standards, makes it possible to define the content of a document separately from its formatting, making it easy to reuse that content in other applications or for other presentation environments. Most important, XML provides a basic syntax that can be used to share information between different kinds of computers, different applications, and different organizations without needing to pass through many layers of conversion.

Web developers are the initial target audience, but database developers, document managers, desktop publishers, programmers, scientists, and other academics are all getting involved. XML provides a simple format that is flexible enough to accommodate wildly diverse needs. Even developers performing tasks on different types of applications with different interfaces and different data structures can share XML formats and tools for parsing those formats into data structures that applications can use. XML offers its users many advantages, including:

• Simplicity
• Extensibility
• Interoperability
• Openness
• A core of experienced professionals

What is XML?

Extensible Markup Language (XML) provides a foundation for creating documents and document systems. XML operates on two main levels: first, it provides syntax for document markup; and second, it provides syntax for declaring the structures of documents. XML is clearly targeted at the Web, though it certainly has applications beyond it. Users who have worked with HTML before should be able to learn the basics of XML without too much difficulty. XML’s simplicity is its key selling point, perhaps even its strongest feature.

XML is derived from (and is technically a subset of) the Standard Generalized Markup Language (SGML). SGML has found its main customer base in organizations handling enormous quantities of documents - the U.S. Government Printing Office, IBM, the U.S. Department of Defense and Internal Revenue Service, and many publishers. SGML’s development provides the foundations for XML, but XML has a smaller and simpler syntax, targeted at web developers and others who need a simple solution to document creation, management, and display.

Note: The following section is not an XML tutorial. It only shows a few pieces of XML to show part of what a document and a DTD look like. For a full tutorial on XML, see my XML: A Primer, or any of a number of other good XML guides arriving at a bookstore near you.

Like HTML (an application of SGML), XML uses elements and attributes, which are indicated in a document using tags. Tags begin with a < and close with a >. End tags include a / before the name of the element; empty tags include a / before the closing >. For example, the following bit of a document includes three elements: two elements with content, and one empty tag.

<FIGURE DESCRIPTION=”Harvey”><IMAGE/><CAPTION>This is a picture of my invisible friend!</CAPTION></FIGURE>

The first start tag opens the FIGURE element, which has the attribute DESCRIPTION set to “Harvey”, and contains an empty IMAGE element and the CAPTION element with its content. End tags close both the CAPTION and the FIGURE elements, producing a nested structure. These nested structures are fairly good at representing typical document and data structures, and a very easy for computer programs to store and manipulate. XML enforces its rules harshly. Unlike HTML browsers, which have been extremely forgiving of bad markup, XML parsers are supposed to produce error messages for illegal or malformed markup. Forcing the author to clean up their markup allows the parsers on the receiving end to do much less work. It also provides authors with confidence that their work will be interpreted consistently, without having to wonder how multiple browsers would interpret the same document.

In addition to providing syntax for document markup, XML provides syntax for specifying document structure. The Document Type Definition (DTD) provides XML parsers a set of rules with which they can validate the document. Validation doesn’t imply that the contents of the document are correct, or that certain data fields are numbers or text; rather, it means that all the elements of the document fit into the structure specified by the DTD. For example, the fragment below specifies the structure used in the example above.

<!ELEMENT FIGURE (IMAGE, CAPTION)>

<!ATTLIST FIGURE
DESCRIPTION CDATA #IMPLIED>

<!ELEMENT IMAGE EMPTY>

<!ELEMENT CAPTION (#PCDATA)>

The FIGURE element must contain an IMAGE and a CAPTION element, and the FIGURE element may have a DESCRIPTION attribute. The IMAGE element must be empty, and would probably include a set of attributes providing information about the image if this example was more complicated than an ‘invisible friend’. The CAPTION element may contain text, entities, processing instructions, and any other valid XML text except other elements. The full syntax for DTDs provides many more options for declaring elements and attributes and their location in the document structure, as well as entities, which allow the developer to define a chunk of XML content or DTD information and use it by reference.

XML permits the use of documents, called ‘well-formed documents’ that use only its rules for document syntax, without specifying a DTD. Documents that contain (and/or refer to) a properly written DTD, and meet the requirements it sets, are referred to as ‘valid’. Validation can be an important step in the authoring process, and may also be performed at any step in processing. Developers can choose how often, and when, to screen a document to check its structure. Applications which need to process lots of information quickly, or which can’t afford the additional processing requirements imposed by validation, can stick to well-formed documents. Well-formed documents also provide an easy bottom rung on the XML learning ladder - by sticking to the basic syntax, developers can create parseable documents with any structure they choose, moving up to more formal DTDs when the need arises.

In practice, though, XML itself should disappear into the background, hiding behind tools for most users. Most people won’t need to create their own DTDs - once a standard DTD is created, users can simply apply it, making modifications when it becomes clear the structure needs improvement. As XML becomes ubiquitous (and tools improve), it should become invisible to all but a few, buried underneath authoring tools and plug-in parsers.

Simplicity

XML provides both programmers and document authors with a friendly environment, at least by computing standards. XML’s rigid set of rules helps make documents more readable to both humans and machines. XML document syntax contains a fairly small set of rules, making it possible for developers to get started right away. DTDs can be developed through a standards process, set by experts, or through experimentation, based on the structures of documents that seem to work well. XML parsers are also reasonably simple to build, especially parsers that only check well-formedness.

XML documents are built upon a core set of basic nested structures. While the structures themselves can grow complex as layers and layers of detail are added, the mechanisms underlying those structures require very little implementation effort, from either authors or developers. These basic structures can be used to represent complex sets of information, from the full contents of a document to persistent object state information to a set of commands for a program, without needing to change the structures themselves.

Extensibility

XML is extensible in two senses. First, it allows developers to create their own DTDs, effectively creating ‘extensible’ tag sets that can be used for multiple applications. Second, XML itself is being extended with several additional standards that add styles, linking, and referencing ability to the core XML set of capabilities. As a core standard, XML provides a solid foundation around which other standards may grow.

Creating DTDs is most likely what the creators of XML had in mind when they called it Extensible Markup Language. XML is, after, a meta-language, a set of rules that can be used to create sets of rules for documents. In a certain sense, there’s no such thing as an ‘XML document’ - all the documents that use XML-compliant syntax are really using applications of XML, with tag sets chosen by their creators for that particular document. XML’s facilities for creating DTDs give standard-builders a set of tools for specifying what document structures may or must appear in a document, making it easy to define sets of structures. These structures can then be used with XML tools for authoring, parsing, and processing, and used by applications as a guide to the data they should accept.

At the same time that XML is being used to create other standards, other supporting standards for XML are being defined. XML can already use many of the standards applied to HTML, like Cascading Style Sheets (CSS) and HyperText Transfer Protocol (HTTP). W3C working groups are developing additional supporting standards for XML. XML-Linking (XLink) provides linking facilities that are far more sophisticated than those in HTML. XPointers, derived from the Text Encoding Initiative’s (TEI) extended pointers, provide a way to consistently reference portions of documents. Extensible Style Language (XSL) provides a more complete set of formatting tools than CSS, and is notable for using XML syntax to define its style sheets. Other standards, including support for data-typing, are under discussion.

Interoperability

XML can be used on a wide variety of platforms and interpreted with a wide variety of tools. Because the document structures behave consistently, parsers that interpret them can be built at relatively low cost in any of a number of languages. XML supports a number of key standards for character encoding, allowing it to be used all over the world in a number of different computing environments. XML complements Java, another force for interoperability, very well, and a considerable amount of early XML development has been in Java. A generic application programming interface (API) for parsers, the Simple API in XML (SAX), is freely available. Parsers are also available in C++, C, JavaScript, Tcl, and Python, with more on the way. XML parser development so far has focused on freeware plug-ins that provide parsing capabilities to XML applications, greatly lowering the cost of building XML-enabled applications.

Openness

Although there have been some questions about the process used to create XML, the standard itself is completely open, freely available on the web. The W3C members have early access to standards (and, apart from invited experts, are the only ones who can participate directly in their creation), but once the standard is complete the results are public. The XML Working Group and the Working Groups for the supporting standards also release drafts of their work on a regular basis, making it possible to follow work in progress. Several non-W3C XML developments have also been extremely open, including SAX.

XML documents themselves are also considerably more open than their binary counterparts. Anyone can parse a well-formed XML document, and validate it if a DTD is provided. While companies may still create XML that behaves in a specific way bound to their application, the data in the XML document is available to any application. While developers could create obfuscated DTDs or encrypt their data in a proprietary manner, they would lose most of the benefits of using XML. XML doesn’t bar the creation of proprietary formats, but its openness is one of its greatest advantages. Application developers can partition tasks among multiple tools, possibly even from different vendors, allowing them all to operate on the same structured data set.

Experience

Successful application of XML will require data modeling expertise and (eventually) the building of a new set of tools. Fortunately, the skills of the SGML community are mostly transferable, providing XML with a large group of ‘experts’ early in its existence. The XML specification was created for the most part by a group of experienced SGML developers, and has received vocal support from many sectors of the SGML community. Vendors are repurposing their tools, simplifying them for XML. Authors who had been writing SGML texts are focusing on XML as well, bringing markup structure to a wider audience. Companies that need to bring in outside vendors to help with large projects have a pool of firms with established track records to choose from.

Putting XML to Work

XML was designed, first and foremost, to be “straightforwardly usable over the Internet.” XML’s first home, and the application it rides to ubiquity, is likely to be the Web. This doesn’t mean that XML by itself will revolutionize the Web, or that the Web is the only field in which XML is going to be useful. In the long run, XML may become a common thread uniting a wide variety of applications, smoothly managing data across distributed applications.

The Web will (hopefully) be XML’s starting point, the ‘killer app’ for XML. XML and CSS together provide developers with an easy and efficient way to mark up pages for presentation on the web. Simply as a web-development system, XML and CSS can already provide significant advantages over HTML, both for ease of use and for the amount of time needed to create a large site. Because CSS allows designers to centralize formatting information in a style sheet shared by any number of documents, designers only need to design repetitive pages once. The formatting information in the style sheet will link to the XML tags in the document, allowing documents to be marked up by editors based on content without the need to enter precise formatting. Complex pages, like the front pages of many sites, will still need extra attention, but the bulk of pages can be built at a reduced cost. Also, because style sheets can centralize all the formatting information needed for a site, XML sites may actually use less bandwidth than their older HTML equivalents.

While formatting pages is useful, many users are starting to realize that web sites are only marginally more useful than printed or faxed material. Although it’s possible to cut and paste information out of a web browser, XML opens up the prospect of reusable page content. With appropriate supporting applications, a user could extract the XML data from a document and keep it in their own private data store, making it easy to manipulate the information later. This information could include site maps, price lists, product information, or nearly any kind of data that can be represented as text. Content-based XML markup enhances searchability as well, making it possible for agents and search engines to categorize data instead of wasting processing power on context-based full-text searches.

At the same time, XML is useful for much more than Web pages. XML’s potential as a universal transfer format, allowing even applications of different types to exchange data smoothly, holds as much promise as its role as a document system. XML browsers are a key opening for XML, allowing users to read XML documents freely, but browsers are only the beginning. XML provides a gateway for communication between applications, even applications on wildly different systems. As long as applications can share data (through HTTP, file sharing, or another mechanism), and have an XML parser, they can share structured information that is easily processed. Databases can trade tables, business applications can trade updates, and document systems can share information.

XML provides a core set of standards developers can use to create their own standards. While some have declared that XML will ‘balkanize’ the Web, the effects are likely to be much more complex - and less destructive - than that suggestion implies. By hammering down a common document syntax, but allowing developers to go their own ways on markup elements, XML makes it possible to create new systems for data management and organization without the many of the incompatibilities and complexities that plagued older systems.

The source of this article is here.

* SOAP ENCODING RULES: Defines a mechanism for exchanging instances of application defined data types. An encoding rule means an encoding style to know how it is applied to a specific data.

* SOAP RPC: Defines a method to represent Remote Procedure Calls and responses. Soap RPC uses a request/response model for message exchanges. The request that is sent to the end point is the call and the response it sends represents the result of the call sent.

SOAP has the following features:

* PROTOCOL independence
* LANGUAGE independence
* PLATFORM AND OS independence
SOAP is a way by which programs communicate with other programs using XML.SOAP uses XML to encapsulate data that needs to be sent to a remote subroutine. In more simple terms SOAP is a way by which Java objects and COM objects communicate with each other. A SOAP client is a program that creates an XML document that contains information required to invoke a method remotely in a distributed system.

A SOAP server is a code that listens to the SOAP messages and acts as a distributor and an interpreter. SOAP defines encoding rules called Base level codings. The encodings can be either
* SIMPLE ENCODINGS
* COMPOUND ENCODINGS

SIMPLE ENCODINGS are simple types like ints, floats, strings or user defined data types. These include data types such as arrays of bytes and Enumerations.

COMPOUND ENCODINGS include data types such as arrays and structures.

See the source…

“SQLXML is a set of supplemental tools that extend SQL Server’s existing support for retrieving and storing XML data. With SQLXML 3.0, you are now able to use SQL Server to expose Web services. SQLXML’s Web services let you execute stored procedures, user-defined functions, and they support templates.

While SQLXML’s Web services capabilities do not offer the flexibility or portability that can be gained by developing your own Web service applications to access data, they are ideal for rapid application development because you can offer SQLXML Web services without writing any code! In addition, the technology is well-suited for exposing reports over the Web. You can develop a client application that consumes SQLXML Web services with very little client-side code. From there, you have a number of options to shape, format, or parse the result set.

In this article you’ll see how to expose a stored procedure as a Web service and build a simple ASP.NET Web Form-based client to access and test the Web service.

You should have a basic of understanding of SQL Server 2000 and IIS, including knowledge of how to setup a virtual directory in IIS and how to grant permissions to a user in SQL Server. You can find basic documentation on these subjects in SQL Server 2000 Books Online and in the SQLXML 3.0 Documentation . To begin, you need an instance of SQL Server 2000, a Windows 2000 server running IIS, Microsoft’s MSXML 4.0 XML parser, the SQLXML 3.0 toolkit, and Visual Studio .NET (VS.NET). You can download the XML parser and SQLXML tools and documentation from the SQLXML resource link in the Resources column of this article.

Configuring a Web Service
The demonstration application for this article uses the Northwind sample database that’s installed by default with SQL Server. To get started, follow the instructions in the SQLXML 3.0 Documentation, available for download with the SQLXML 3.0 installer.

First, perform the steps in the procedure labeled Creating the nwind Virtual Directory under the topic IIS Virtual Directory Management for SQL Server in the SQLXML 3.0 documentation.

Go to the Configure IIS Support MMC snap-in application under the SQLXML 3.0 program group.

Select the default web site for your server, go to the Action menu and select New, then click on Virtual Directory.

Create a virtual directory named nwind under IIS that supports SQLXML applications accessing the Northwind database.

Configure the security settings to support the access to the Northwind database by the virtual directory application.

Under the Settings tab, check the Allow Post option. This allows HTTP POST requests, which are required to support SQLXML Web.

Under this virtual directory, you can configure different types of SQLXML applications, including templates, schemas, and dbobjects, which support template execution, XPath queries against a mapping schema file, and direct access of database objects respectively. These different types of applications under the virtual directory are called virtual name types. There is also a SOAP virtual name type that identifies Web services using SOAP messaging. Create a SOAP virtual name type and name it MyWebService. Now you need to follow the steps in the section labeled Step 2: Configuring the Virtual Name under the topic Initial Setup for Sending SOAP Requests.

Enter MyWebService as the name for the new virtual directory application and select the virtual name type SOAP. This creates a reference to the Web Service extensions of the Northwind database. Configuring MyWebService creates a WSDL (Web Services Definition Language) file and a SQL Server Configuration (.ssc) configuration file for your Web service. The .ssc file describes the virtual name type configuration, and SQLXML uses it to generate the WSDL file. The WSDL file describes the Web services and the methods that your client application can call when using the service.

After setting up a SOAP virtual name type, select the Configure option under the Virtual Names tab of the IIS Virtual Directory management tool for SQLXML 3.0. To set up a stored procedure method mapping type for your soap virtual name type, select the CustOrdersDetail stored procedure under SP/Template option and select the Save option. Saving the stored procedure mapping adds a CustOrdersDetail method to MyWebService. After completing this step, browse to your nwind virtual directory and look for a file named soap.wsdl, which is the XML-formatted WSDL file that describes the services you configured. In a text editor the file looks like this:

<xsd:element name="CustOrdersDetail">

<xsd:complexType>

<xsd:sequence>

<xsd:element minOccurs="0" maxOccurs="1"

name="OrderID" type="xsd:int"

nillable="true"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="CustOrdersDetailResponse">

<xsd:complexType>

<xsd:sequence>

<xsd:element minOccurs="1" maxOccurs="1"

name="CustOrdersDetailResult"

type="sqlresultstream:SqlResultStream"/>

<xsd:element name="returnValue"

type="xsd:int" nillable="true"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>"

See the source.

Middleware computing provides a central point of access to many systems, database driven or not. Middleware also performs rules based processing on data that is being translated. The middleware approach is expensive to build and may be overkill for a specific application. It is slower than database created XML for data that is not changing frequently.

Retrieving Data from SQL database

There are two different methods of generating XML from within SQL server. One way is to use Web Assistant Wizard, to create Web Tasks, which are automated tasks that run at specific intervals and generate either HTML or XML files, or the second way is to use stored procedures to return results sets that are formatted into XML.

Also using Web Assistant Wizard it is possible to create Web Task that generates the XML file that retrieves the data from SQL database and displays it in the browser.

Microsoft’s SQL feature is to make the generation of HTML files from SQL. There is no reason to build custom Web software that interactively queries for the data and builds HTML results. Web Tasks are designed and are meant to generate an HTML. An XML specification is not complete when Web Tasks are added to SQL server.

Web Tasks automatically creates the XML file based on the template created by the user and the settings given in the Web Assistant Wizard. The XML files retrieves the data from SQL Server and displays it to the user and viewed from the browser. To access the database using XML, an example is given below.

A table is created called “Bookinfo“ with the columns BName, Author, AuthorADD, Phone, Publisher and PublisherADD in SQL Server database and insert rows. A template file called “Bookinfo.tpl” is also created and the Web Assistant Wizard is used to create the Bookinfo.xml file.

The real flexibility of the template feature of SQL Server is the ability to use it to generate XML. The server does not care whether the file contains all anything other than the keywords it uses to insert current row data. Three files,one the template file called Bookinfo.tpl, one the DTD file called the Bookinfo.dtd and one CSS file called Bookinfo.css.

The CSS file contains the codes for styling format. The keywords <%begindetail%>, <%enddetail%> and <%insert_data_here%> are the ASP code used to fetch the data from SQL database. <%begindetail%> and <%endetail%> are used to mark the area where SQL query’s results set should be used to fill the <%insert_data_here%> statements. It indicates where column data should be placed from the results set. The following is the code for Bookinfo.tpl.

<?xml version=”1.0”?>
<?xml-stylesheet href=”Bookinfo.css” type=”text/css”?>
<!doctype penta SYSTEM “Bookinfo.dtd”>
<penta>
<pentabody>
<toptitle>Online books dot com</toptitle>
<weltext>Welcome to online books</weltext>
<bodytext>Happy to inform the facility of reading the following books online at free of cost</bodytext>
</pentabody>
<Bookinfo>
<%begindetail%>
<Entry>
<BName ><%insert_data_here%></BName>
<Author><%insert_data_here%></Author>
<AuthorADD><%insert_data_here%></AuthorADD>
<Phone><%insert_data_here%></Phone>
<Publisher><%insert_data_here%></Publisher>
<PublisherADD><%insert_data_here%></PublisherADD>
</Entry>
<%enddetail%>
</Bookinfo>
<Foot>
<Footer>Online books for demonstration</footer>
</Foot>
</penta>

The following is the code for Bookinfo.dtd

<!ELEMENT penta (pentabody, Bookinfo, Foot)>
<!ELEMENT pentabody (toptitle, weltext, bodytext)>
<!ELEMENT toptitle (#PCDATA)>
<!ELEMENT welltext (#PCDATA)>
<!ELEMENT bodytext (#PCDATA)>
<!ELEMENT Bookinfo (Entry)>
<!ELEMENT Entry (BName, Author, AuthorADD, Phone, Publisher, PublisherADD)>
<!ELEMENT BName (#PCDATA)>
<!ELEMENT Author (#PCDATA)>
<!ELEMENT AuthorADD (#PCDATA)>
<!ELEMENT Phone (#PCDATA)>
<!ELEMENT Publisher (#PCDATA)>
<!ELEMENT PublisherADD (#PCDATA)>
<!ELEMENT Foot (#PCDATA)>
<!ELEMENT Footer (#PCDATA)

See the source…

XQuery Saving Lives: Data Integration Using DataDirect XQuery

The information, collected since 1997 under the Electronic Car Crash Data System, averages out data involving approximately 5,000 accidents every year. Data is collected in 24 sites around the country and consolidated in a large Oracle database (500 GigaBytes). NHTSA wanted to make the information available to several groups of people, including Department of Transportation researchers, insurance company investigators, vehicle manufacturers and the general public.

Previously, all data distribution had taken place using flat files and various proprietary formats; new federal regulations and technology evolution empowered the Volpe Center to move to the current open standard: XML.

Doing Things the Old-Fashioned Way

Initially, the engineers at the Volpe Center explored using a conventional approach — SQL queries driven by Java code. They determined that moving data from a database into XML using SQL and Java would require about 50 Java classes and 150 SQL statements for one study type. Obviously, a project of this magnitude would be complex to design and debug, and would require considerable maintenance of code.

Doing Things a Better Way

After careful consideration in November 2005 it was determined that a better option was to store the data in an XML repository. The Volpe Center decided to use DataDirect XQuery® to handle their XML and relational tasks. XQuery allowed them to move all the data directly into XML files validated against the specific Car Crash XML-schema design; all the XQueries for sub processing data features such as search and dataset construction, are performed against the XML files. The new architecture enabled by DataDirect XQuery requires just a single Java class and 7 XQueries. Each XQuery encapsulates the transformation rules clean of any other type of code, considerably reducing maintenance efforts, and simplifying code.

“Building the XML repository from the Oracle relational database and later executing the XQueries on the XML to traverse the data resulted in amazing performance,” reports Juan Alfonso, senior software engineer at Core Computer Group, a TRIPS project contractor. “Moreover, a large extraction from 500MB of XML data building datasets intended for SAS analysis took significantly less time compared to using different methods. Simple XQueries with XPath expressions pointing to the XML repository locations performed easily using the DataDirect XQuery implementation.”

Get The Information to the People

DataDirect and the TRIPS project team at the Volpe Center were instrumental in developing the National Highway Traffic Safety Administration’s new system, which allows their customers to access important information quickly, efficiently, and reliably. DataDirect XQuery, from Core Computer Group’s perspective, was instrumental in enabling the Volpe Center to efficiently deliver a powerful and reliable solution to their customer.

“DataDirect XQuery is the one that worked, and it worked with excellent performance, which we demonstrated with our project,” Alfonso says in summing it up. “With DataDirect XQuery we were able to reduce code complexity, simplify code maintenance and improve performance and scalability.”

“Additionally, the next release of our series of car crash studies will deploy a set of new features like dynamic search capabilities and custom dataset creation. The processing will be performed using a backend generic XQuery factory, based on DataDirect XQuery. The advantage to doing this process directly from the XML repository, is that it will allow us to isolate the final-public-deliverable data from the Oracle production database.”

Goal: Real-time lookup and distribution of high-volume data from XML and a large (500 GB) database.

Why they selected DataDirect: By moving away from more conventional approaches (such as Java code and SQL query statements), and exploring different XQuery implementations, DataDirect XQuery was the most efficient solution for both the relational to xml and later XML to XML data integration.

Business benefits: National Highway Traffic Safety Administration was able to provide a way for their researchers and customers to access the Car Crash Information Collection database quickly and efficiently while saving development time and effort.

Technical benefits: By choosing DataDirect XQuery, the Volpe Center and the TRIPS contractors were able to move the data to XML files residing on the file system and to drastically simplify the query code. The architecture the Volpe Center developed using XQuery is powerful, efficient, stable, and easy to maintain.

Source : DataDirect Technologies

In 1986 the Standard Generalized Markup Language (SGML) became an international standard for defining descriptions of the structure and content of different types of electronic documents. SGML, the “mother tongue” of HTML and XML, is used for describing thousands of different document types in many fields of human activity, from transcription of ancient Sumerian tablets to the technical documentation for stealbombers, and from patient’s clinical records to musical notations.

SGML has withstood the test of time. Its popularity is rapidly increasing among organizations with large amounts of document data to create, manage, and distribute as in the Defense, Aerospace, Semiconductor and Publishing industries. However, various barriers exist to delivering SGML over the Web. These barriers include the lack of widely supported stylesheets, complex and unstable software because of SGML’s broad and powerful options, and obstacles to interchange of SGML data because of varying levels of SGML compliance among SGML software packages.

These difficulties have condemned SGML to being a successful niche technique rather than a mainstream tool. Indeed some cynics have renamed SGML in ‘Sounds Good Maybe Later’.

HTML

HTML is a subset of SGML, the most frequently used document type in the Web. It defines a single, fixed type of document with markup that lets you describe a common class of simple office style report, with headings, paragraphs, lists, illustrations, etc., and some provision for hypertext and multimedia.

HTML was defined to allow the transfer, display and linking of documents over the internet and is the key enabling technology for the WWW. Prior to the emerging of the internet, it was unusual in the word of computing to hear the word “page” used to describe elements of data. But HTML web pages have amazing similarities with paper in their role of information publishing. Both HTML and paper pages
are optimized for visual clarity,
focus on ultimate usability (but not on reusability),
contain no contextual information, and
have no document structure to enable automation.

Today’s web is created by Hand for Eyes only. HTML has too low an “Information IQ” to enable many desirable applications. HTML was designed as a markup language an with simple structures, strong emphasis on formatting and was weak for encoding content. It was not designed to encode structure and semantics needed for complex applications.

XML

Because of the lack of SGML support in mainstream Web browsers, most applications that deliver SGML information over the Web convert the SGML to HTML. This down-translation removes much of the intelligence of the original SGML information. That lost intelligence virtually eliminates information flexibility and poses a significant barrier to reuse, interchange, and automation.

For this reason, XML (Extensible Markup Language) was developed by the XML working group (known as the SGML Editorial Review Board) formed under the auspices of the World Wide Web Consortium (W3C) in 1996. XML is a highly functional subset of SGML. The purpose of XML is to specify an SGML subset that works very well for delivering SGML information over the Web. When the mainstream Web browsers support XML, it is believed that it’s going to be very easy to publish SGML information on the Web. It’s actually misnamed because XML is not a single Markup Language. It is a metalanguage to let users design their own markup language.

XML is a public format and not a proprietary format of any company. The v 1.0 specifications was accepted by the W3C as Recommendation on February 10, 1998.

XML was conceived as a means of regaining the power and flexibility of SGML without most of its complexity. While retaining the beneficial features of SGML, XML removes many of the more complex features of SGML that make the authoring and design of suitable software both difficult and costly. But XML also lacks some important capabilities of SGML that primarily affect document creation, not document delivery. That’s because XML was not designed to replace SGML in every respect.

The question that is open is not whether XML will succeed as a widespread data format, but rather how fast, to what level of success and with what products. The question of whether XML would enter the market was answered when Microsoft, Adobe, Netscape and other big market players not only supported the development of the new standard but began making sizable product investments to this new format. The leading Web browser Products already support XML in their latest releases. The momentum building behind the XML effort means that XML is inevitably destined to become the mainstream technology for powering broadly functional and highly valuable business applications on the Internet, intranets, and extranets.

XHTML

XHTML is a working draft for there formulation of HTML 4.0 [HTML] as an application of XML 1.0 [XML]. It is the basis for a family of future document types that extend and subset HTML.

There are two major reasons for content developers to adopt XHTML. First, XHTML is designed to be extensible (Design you own tags). Second, XHTML is designed for portability. There will be increasing use of non-desktop user agents to access Internet documents. Some estimates indicate that by the year 2002, 75% of Internet document viewing will be carried out on these alternate platforms. In most cases these platforms will not have the computing power of a desktop platform, and will not be designed to accommodate ill-formed HTML as current user agents tend to do. Indeed if these user agents do not receive well-formed XHTML, they may simply not display the document.

Source JavaCommerce

XQuery is the official W3C XML Query language for querying XML along with any data source with an XML representation. It provides a powerful language constructs which somewhat resembles SQL and XPath, and is designed for using XML in the context of an SQL enabled relational database, thus providing the ability to create, insert, and update XML data directly. Support of XQuery-based relational to XML mapping technologies in Stylus Studio® provides a powerful, extensible, and cost-effective solution for accessing relational data as XML, a frequently encountered challenge in any advanced data integration application.

Database-to-XML Mapping with Any Database

Our Database-to-XML Mapper supports access all of the leading relational databases; support for Microsoft SQL Server, Oracle, IBM DB/2, Sybase and many others. Support for accessing any relational database via XQuery is accomplished through integrated support for DataDirect XQuery™, a Java-implementation of XQuery that can query XML, relational data as well as SOAP messages, EDI, legacy data formats, or a combination of data sources. DataDirect XQuery™ provides the fastest, most reliable, and most scalable XQuery support for all major relational databases, and it runs on any Java platform. DataDirect XQuery™ supports the XQuery for Java API (XQJ), and is easily embeddable in any Java program — it does not require any other product or application server, and it has no server of its own. DataDirect XQuery™ is recommended for applications that must manage XML, relational, and legacy data formats, including applications for data integration, Web services, Web publishing, and report generation.

Visual Database to XML Mapping

Stylus Studio® provides a visual Relational to XML mapping tool (illustrated below) for creating, editing, and testing the XQuery statements used to define any relational database tables and views as a customized XML data source. Once you’ve created a connection to a relational database, you first browse the database contents using our file explorer which includes support for browsing Database objects such as tables and views. Our XQuery Mapper automatically generates the XQuery code required to query (or update) relational database tables and views — just drag and drop your relational database sources to the datasource pane and visually map from source to target output document, specifying the processing you’d like to take place. Our relational to XML database mapping tools implements the mapping code using none other than industry-standard XQuery code.

Viewing a Database to XML Mapping

You can execute your newly created database to XML mappings to verify that it produces the desired XML data source from your relational data. To run the database to XML application, simply click the Execute Query button and the XML results are displayed in a Preview window. Once you are satisfied with the results, save the resulting XQuery file.

Stylus Studio® provides a powerful, standards-based solution for accessing relational data and rendering it as XML. Visual XQuery editing, testing, and built-in support for DataDirect XQuery™ makes it easy to visually map, query and update relational databases as XML and save them as XML data sources that can be used anywhere you use XML — to build XQuery, XSLT, even Web services — Download a free trial now!

Web Services Policy 1.5 Based on Industry Needs, Experience

Years of customer experience with commercial Web services applications have made clear the need for a modular approach for describing required and optional extensions used by a service. Without this capability, it can be costly to rewrite an entire service whenever application needs change. Web Services Policy 1.5 can reduce this cost. It connects the core Web services standards — SOAP 1.2, WSDL 2.0, and XML Schema — to a growing set of extensions that reflect industry needs and experience.

The W3C Web Services Policy Working Group invited implementers to demonstrate interoperability by evaluating software against the group’s test suite. Ten implementations of Web Services Policy 1.5 helped confirm the maturity of the specification. The tests focused on security assertions, one of the most important use cases cited by industry.

Another use case, addressing metadata, is the focus of W3C’s WS-Addressing Working Group. The two W3C Working Groups have collaborated to ensure that the Addressing Metadata Specification is aligned with the policy framework.

The W3C Web Services Policy Working Group also secured review from several OASIS Web Services Technical Committees (UDDI, WS-RX, WS-TX, and WS-SX) to ensure that Web Services Policy 1.5 would satisfy their use cases.

Web Services Working Group Brings Together Industry Leaders

The Web Services Policy Working Group brings together leaders from across the software industry including Adobe Systems Inc; Axway Software; BEA Systems, Inc; CA; Fujitsu Limited; IBM; IONA Technologies, Inc.; JBoss Inc.; Layer 7 Technologies; Microsoft Corporation; Nokia; Nortel Networks; Oracle Corporation; SAP AG; Sonic Software; Sun Microsystems, Inc.; webMethods, Inc.; and WSO2.

Source: W3C