Abstract

XML is a very basic technology for representing trees using a standardized markup-based syntax. An increasing number of technologies are building on this foundation, creating an expanding field of XML-based technologies for interoperability in many different fields. Application-specific XML-based data formats are used in many different settings, and the best data format for a given scenario depends on the existing formats in this area and the exact requirements. More interestingly, generic XML technologies which can be applied in many different settings make it easier for developers and system integrators to achieve their goal of making system interoperate.

XML-Based Distributed Programming

• XML exchanges often have to be negotiated in advance
  • the transport mechanism need to be defined
  • the schema(s) need to be defined
  • the possible interactions between peers need to be defined
• Web Services are a well-defined environment for XML exchanges
• Two very different approaches to XML-based distributed programming
  1. instead of programming-language specific mechanisms, have your components talk to each other in XML
  2. instead of simply wrapping APIs in XML, redesign your IT landscape into loosely coupled systems

Web Service Technologies

• Simple Object Access Protocol (SOAP)
  • SOAP messages have an envelope for Web Service Metadata
  • SOAP messages have a body containing the actual payload
  • non-XML data can be attached in the same way as for e-mail messages
• Web Service Description Language (WSDL) for describing SOAP-based services
  • the payload format must be known
  • the different messages that may be sent must be known
  • the transport mechanism must be known
  • the address where to send the SOAP to must be known
• Universal Description, Discovery, and Integration (UDDI) for making WSDL available
  • UDDI is intended to be a repository for WSDL descriptions
  • UDDI is not a global service like the DNS
  • UDDI is modeled after yellow pages

SOAP Example Message

<?xml version="1.0"?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
 <env:Header>
  <m:reservation xmlns:m="http://travelcompany.example.org/reservation" env:role="http://www.w3.org/2003/05/soap-envelope/role/next" env:mustUnderstand="true">
   <m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference>
   <m:dateAndTime>2001-11-29T13:20:00.000-05:00</m:dateAndTime>
  </m:reservation>
  <n:passenger xmlns:n="http://mycompany.example.com/employees" env:role="http://www.w3.org/2003/05/soap-envelope/role/next" env:mustUnderstand="true">
   <n:name>Åke Jógvan Øyvind</n:name>
  </n:passenger>
 </env:Header>
 <env:Body>
  <p:itinerary xmlns:p="http://travelcompany.example.org/reservation/travel">
   <p:departure>
    <p:departing>New York</p:departing>
    <p:arriving>Los Angeles</p:arriving>
    <p:departureDate>2001-12-14</p:departureDate>
    <p:departureTime>late afternoon</p:departureTime>
    <p:seatPreference>aisle</p:seatPreference>
   </p:departure>
   <p:return>
    <p:departing>Los Angeles</p:departing>
    <p:arriving>New York</p:arriving>
    <p:departureDate>2001-12-20</p:departureDate>
    <p:departureTime>mid-morning</p:departureTime>
    <p:seatPreference/>
   </p:return>
  </p:itinerary>
  <q:lodging xmlns:q="http://travelcompany.example.org/reservation/hotels">
   <q:preference>none</q:preference>
  </q:lodging>
 </env:Body>
</env:Envelope>

WSDL Example (Google)

 <portType name="GoogleSearchPort">
  <operation name="doGetCachedPage">
   <input message="typens:doGetCachedPage"/>
   <output message="typens:doGetCachedPageResponse"/>
  </operation>
  <operation name="doSpellingSuggestion">
   <input message="typens:doSpellingSuggestion"/>
   <output message="typens:doSpellingSuggestionResponse"/>
  </operation>
  <operation name="doGoogleSearch">
   <input message="typens:doGoogleSearch"/>
   <output message="typens:doGoogleSearchResponse"/>
  </operation>
 </portType>

UDDI Data Model

HTML Forms Limitations

• HTML forms are very popular for data entry
  • many Web-based applications use HTML forms as their interface
  • the features offered by HTML forms are very poor
• HTML forms have a lot of limitations
  • they cannot check datatypes (fields are always strings)
  • they cannot create new fields (if data entry requires repeatable fields)
  • they only work in HTML (integral part of the HTML language)
• Workarounds for better Web-based applications are possible
  • JavaScript can be used to provide additional functionality
  • server-side engines can provide a back-end for better forms
  • writing accessible, portable, and usable forms is a challenge

XForms

• XML is the most ubiquitous data format on the Web
  • there is no generally support way to edit or produce XML data
  • forms should be XML-based rather than being based on HTTP/MIME
• XForms define an XML-based model for data editing and input
  • they are separating content from presentation
  • clients are free in their choice of data presentation and acquisition
  • XForms provide an XML-in, XML-out model of data handling
  • XForms can be implemented server- or client-based
• Client-based XForms require browser support
• Server-based XForms require XForms↔DHTML mappings

XForms Limitations

• XForms are good for data-oriented XML
  • regularly structured data
  • no mixed content
• XForms are inappropriate for document-oriented XML
  • irregularly structured data is not well-supported
  • mixed content is not supported at all
• XForms is for forms, it is not a general XML editing facility
  • XML editors often need a lot of customization
  • there is no standards-based way for general-purpose XML editing

XML is Syntax

• XML facilitates the exchange of trees
• XML schema languages define constraints for trees
• The meaning of the data encoded in the tree is unclear
  • XML has no semantics (with the exception of xml:lang)
  • semantics have to be agreed upon before cooperation is possible
  • XML relies on other mechanisms (documentation, formal models)

<?xml version="1.0" encoding="UTF-8"?>
<文書 改訂日付="１９９９年３月１日">
 <題>サンプル</題>
 <段落>これはサンプル文書です。</段落>
 <!-- コメント -->
 <段落>会社名</段落>
 <図面 図面実体名="サンプル" />
</文書>

Semantics

• Semantics can be defined in ontologies
  • ontologies are a formalization of a conceptualization
  • in particular, they are based on a concept for concepts
• By referring to ontologies, cooperation can use shared semantics
  • of course, this only works if people first agree on the ontology
  • domain specialists build ontologies, which are then used for semantics
• Semantic Web technologies revolve around the idea of ontologies
  • Microformats do not have formalized ontologies (just concepts)
  • the Resource Description Framework (RDF) describes resources semantically
  • the ontology is defined using RDF Schema (RDFS) or the Web Ontology Language (OWL)
  • all kinds of AI-style applications are possible using formalized semantics

Islands of Semantics

• Microformats solve very specific problems in a very specific way
  • encoding address information on a Web page
  • encoding a location of something represented by a Web resource
• Microformats can be compared to tagging
  • a very simple mechanism with a minimal barrier-to-entry
  • little flexibility in adapting the mechanism to slightly other uses
  • often underspecified and interpretation implementation-dependent
  • no unified rules across different platforms which makes processing hard
  • nice and easy to start with, but questionable for robust long-term solutions
• Currently there are about 10 reasonably popular microformats
  • calendar entries, addresses, licenses, outlines, geolocation, resumes, social networking, …

Microformat Syntax

• HTML has some underspecified and underused elements
  • dfn, code, samp, kbd, var, cite, abbr, acronym
  • they can be reused and augmented with additional information
• HTML allows non-HTML content in HTML pages
  • unknown elements and attributes must be ignored
• HTML allows class attributes to carry semantics
  • XHTML 2 attempts to move this functionality to a role attribute
• HTML has a head which contains page metadata
  • for example, the link element specifies connections to other resources

Describing Resources

• RDF describes everything in triples
  • making a statement about a resource (identified by a URI
  • describing a certain property of the resource
  • specifying a value for that property

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:contact="http://www.w3.org/2000/10/swap/pim/contact#">
  <contact:Person rdf:about="http://www.w3.org/People/EM/contact#me">
    <contact:fullName>Eric Miller</contact:fullName>
    <contact:mailbox rdf:resource="mailto:em@w3.org"/>
    <contact:personalTitle>Dr.</contact:personalTitle> 
  </contact:Person>
</rdf:RDF>

RDF Graphs

RDF is Simple and Complex

• RDF's abstract model is the idea of descriptive triples
  • the actual RDF model is rooted in description logic
  • RDF itself can only describe individuals (something identified by URI)
• RDF/XML is an XML syntax for encoding triples
  • the syntax allows a variety of ways to represent the same RDF statements
  • processing RDF/XML with XML tools is likely to fail
  • use RDF parsers to parse all variations of RDF/XML into an abstract RDF graph
• RDF Schema supports the creation of RDF vocabularies
  • describe the classes of things that can be used in statements
  • describe the properties which can be used for each of these classes
  • describe the allowed values for the supported properties

RDF Schema Graph

XML is Growing

• XML is the foundation for structured information
• XML is getting closer to programming languages
• XML is becoming the standard toolset for any kind of structured information
• XML itself is simple, but using XML wisely is not always simple
• Schemas and documents may live very long, so plan ahead and choose wisely