XML and Web Services In The News - 5 January 2007

Provided by OASIS | Edited by Robin Cover

This issue of XML Daily Newslink is sponsored by IBM Corporation



HEADLINES:

 All Markup Ends Up Looking Like XML
 JSON Uniform Messaging Protocol (JUMP)
 OASIS Seeks SOA Reference Architecture in 2007
 Web Services Make Connection (WS-MakeConnection)
 OASIS Members Launch Unstructured Operation Markup Language (UOML) TC
 Internet Explorer Vulnerable to Adobe XSS Bug


All Markup Ends Up Looking Like XML
David Megginson, Quoderat Blog
"In the current JSON vs. XML debate (Bray, Winer, Box, Obasanjo, and many others), there are three things that important to understand: (1) There is no information that can be represented in an XML document that cannot be represented in a JSON document. (2) There is no information that can be represented in a JSON document that cannot be represented in an XML document. (3) There is no information that can be represented in an XML or JSON document that cannot be represented by a LISP S-expression. They are all capable of modeling recursive, hierarchical data structures with labeled nodes. Do we have a term for that, like Turing completeness for programming languages? It would certainly be convenient in discussions like this. The only important differences among the three are the size of the user base (and opportunity for network effects), software support, and syntactic convenience or inconvenience. The first two are fickle — where are the Pascal programmers of yesteryear? — so we can concentrate on syntax... with markup, as with coding, there's no silver bullet. JSON (and LISP) have the important advantage that they make the most trivial cases easy to represent, but as soon as we introduce even the slightest complexity, all of the markup starts to look about equally verbose. That means that the real problems we have to solve with structured data are no longer syntactic, and anyone trying to find a syntactic solution to structured data is really missing the point: JSON, XML (and LISP) people would be best making common cause to start dealing with more important problems than whether we use braces, pointy brackets, or parentheses. That's why I was excited to have JSON inventor Doug Crockford speak at XML 2006, and why I hope that we'll get more submissions about JSON as well as XML for 2007. Personally, I like XML because it's familiar and has a lot of tool support, but I could easily (and happily) build an application based on any of the three — after all, once I stare long enough, they all look the same to me..."
See also: the XML-DEV thread 'json v. xml'

JSON Uniform Messaging Protocol (JUMP)
Robert Sayre (ed), IETF Internet Draft
A version -03 draft has been released as an Internet Draft for "JSON Uniform Messaging Protocol (JUMP)." JUMP uses HTTP and a lightweight layout for JSON records to edit the Web. The specification defines a loosely-coupled protocol based on a small set of conventions for JSON records and a profile of HTTP. JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. JSON (IETF RFC 4627) provides an interoperable object serialization format capable of representing numbers, strings, arrays, and a wide range of Unicode characters. In JUMP: No JUMP field is required for every JUMP record, but interoperability will increase as the number of standard fields increases. Thus, a record containing zero standard fields is very unlikely to interoperate with any given JUMP implementation. Records without 'title' or 'text' fields are also unlikely to interoperate with an independently-developed JUMP implementation. JUMP records and fields should contain general type values whenever possible, so that independent implementations can interoperate to some degree. Additionaly, type names should be suitable for use as a MIME parameter value. Text fields are based on the Text Constructs found in RFC 4287 ("The Atom Syndication Format"). JUMP records and arrays can be nested. It is sometimes desirable to edit a single JSON field, rather than replace the whole record; to edit a field, the client uses the familiar slash syntax of URIs to denote the object hierarchy...
See also: JSON RFC 4627

OASIS Seeks SOA Reference Architecture in 2007
Rich Seeley, SearchWebServices.com
In this article, James Bryce Clark, Director of Standards Development for OASIS, talks about how his organization drove a stake in the ground with its SOA Reference Model, defining what SOA is and is not. One of our milestones for 2006 was that the SOA Reference Model committee did issue a standard. It's proving to be a very useful and appreciated piece of work. But let me tell you what it is not. It is not an architecture. It is also not a list of standards. There's a tremendous temptation to say SOA is the following six tools or the following four standards used together. You can sell a lot of software by saying that. The problem is it's not true. Service orientation is a methodology. It's a way of organizing information. An enterprise service orientation most commonly expresses itself as bullet points in an RFP (request for proposal). What you're really doing when you decide to go down the path of service orientation is you are making a decision about the requirements and constraints that you will impose on all the information that you want to expose to interoperate with other people. There are a lot of ways to do it. There are a lot of different methodologies. There are a lot of different modes of expression. There are many different software choices. It is not a bunch of standards or a vendor's product. It's a decision that you want everything you're doing to run a certain way. Then it constrains your choice of methods and vendors and apps and sometimes trading partners. The most interesting thing about the SOA Reference Model is that it got started because a bunch of people who had been working in XML, Web services and other SOA methods were frustrated with the attempt to define service orientation. It actually started as a project to name a set of standards. They thought maybe we can explain it to people in terms of layers. You have to have a registry layer, a messaging layer, a content layer. So the SOA Reference Model was an attempt to come up with a working consensus definition of those basic building blocks on an abstract level, which then could be taken to architectures, to more than one architecture.
See also: W3C XQuery references

Web Services Make Connection (WS-MakeConnection)
OASIS WS-RX TC, Working Draft 01
An initial (version -01) working draft for "WS-MakeConnection" was released by members of the OASIS Web Services Reliable Exchange (WS-RX) Technical Committee. The draft was edited by Doug Davis (IBM), Anish Karmarkar (Oracle), Gilbert Pilz (BEA), Steve Winkler (SAP), and Umit Yalcinalp (SAP). "This specification (WS-MakeConnection) describes a protocol that allows messages to be transferred between nodes implementing this protocol by using a transport-specific back-channel. The protocol is described in this specification in a transport- independent manner allowing it to be implemented using different network technologies. To support interoperable Web services, a SOAP binding is defined within this specification. The protocol defined in this specification depends upon other Web services specifications for the identification of service endpoint addresses and policies. How these are identified and retrieved are detailed within those specifications and are out of scope for this document. By using the XML, SOAP 1.1, SOAP 1.2, and WSDL 1.1 extensibility model, SOAP-based and WSDL-based specifications are designed to be composed with each other to define a rich Web services environment. As such, WS-MakeConnection by itself does not define all the features required for a complete messaging solution. WS-MakeConnection is a building block that is used in conjunction with other specifications and application-specific protocols to accommodate a wide variety of requirements and scenarios related to the operation of distributed Web services... The WS-Addressing specification defines the anonymous URI to identify non-addressable endpoints and to indicate a protocol-specific back-channel is to be used for any messages destined for that endpoint. For example, when used in the WS-Addressing ReplyTo EPR, the use of this anonymous URI is meant to indicate that any response message is to be transmitted on the transport-specific back-channel. In the HTTP case this would mean that any response message is sent back on the HTTP response flow. In cases where the connection is still available the WS-Addressing URI is sufficient. This specification defines a mechanism by which a new connection can be established. The MakeConnection model consists of a two key aspects: (1) An optional anonymous-like URI template is defined that has similar semantics to WS-Addressing's anonymous, but also allows for each non-addressable endpoint to be uniquely identified; (2) A new message is defined that establishes a connection that can then be used to transmit messages to these non- addressable endpoints. The MakeConnection message is used to establish a new connection between the two endpoints. Within the message is identifying information that is used to uniquely identify a message that is eligible for transmission..."
See also: the WS-RX TC web site

OASIS Members Launch Unstructured Operation Markup Language (UOML) TC
Staff, OASIS Announcement
OASIS announced that members have formed a new "OASIS Unstructured Operation Markup Language (UOML) Technical Committee" with a Call for Participation. The purpose of this TC is to create an open, XML-based operation standard for unstructured documents. The Unstructured Operation Markup Language specification will define an XML schema for universal document operations. The schema is suitable for operating printable documents, including create, view, modify, and query information, that can be printed on paper, e.g. books, magazine, newspaper, office documents, maps, drawings, blueprints, but is not restricted to these kinds of documents. There are several commercial and free applications available based on the current draft of UOML cited below, with more currently under development. The anticipated audience for this work includes makers of document related applications, Docbase providers, and other specification writers that need document operations or parts of it. Developers and users of office application and document formatting specifications such as the OASIS OpenDocument Format ("ODF") may find UOML useful. However, UOML addresses a different set of functions. The proposed UOML specification will operate on layout-based formatting information, rather than content- based formatting information (such as ODF). UOML will limit its functions to abstracting data from paper form, and defines an operation interface, rather than a file storage format. It is expected that the existing UOML specification will be contributed to the TC by Sursen Co., along with possible additional contributions from HanWang Technology Co., TRS Information Technology Co., Redflag Chinese 2000 Software Co., and the Institute of Software, Chinese Academy of Sciences. The TC will operate under the RAND Mode under the OASIS IPR Policy.
See also: the UOML TC web site

Internet Explorer Vulnerable to Adobe XSS Bug
Gregg Keizer, InformationWeek
Adobe says that Reader 8.0, which was launched a month ago, was invulnerable to the cross-site scripting bug, and recommended that all users update to that [8.0] version immediately. Security researchers on Thursday reported that some versions of Microsoft's market-leading Internet Explorer browser are vulnerable to a critical bug in Adobe's popular Reader software. The vulnerability in Adobe Reader's browser plug-in, which was publicized Wednesday by several security companies, can let hackers force trusted Adobe PDF (Portable Document Format) files to run malicious JavaScript code on victimized PCs. Early Wednesday, Symantec researchers insisted that only Firefox 1.5 and Opera 9.10 were vulnerable to a possible exploit; by Thursday, however, additional research had confirmed that some versions of Internet Explorer are at risk. According to an updated DeepSight threat network alert, IE 6.0 on XP SP2 equipped with Adobe Reader 6, as well as IE 6 on XP SP1 running Reader 7, are vulnerable. Also at risk: Firefox 1.5, Firefox 2.0, and Opera 9.10 when running either Reader 6 or 7. "Version 6 of Internet Explorer is impacted," says David Cole, director of Symantec's security response group. "The best way for enterprises and users to protect themselves is to update Adobe Reader." An exploit could be as simple as a link to a PDF file embedded in an instant message, Cole theorizes. "The IM could say 'check out this file,' and you don't notice the gobbledygook after the PDF's [filename], so you click on it. You go to a site that looks legit, and because that's the URL you saw, you trust it. But then you get a message box that asks you to fill in your password information here or maybe it's a new promotion that asks you to fill in the blanks."


XML.org is an OASIS Information Channel sponsored by BEA Systems, Inc., IBM Corporation, Innodata Isogen, SAP AG and Sun Microsystems, Inc.

Use http://www.oasis-open.org/mlmanage to unsubscribe or change an email address. See http://xml.org/xml/news_market.shtml for the list archives.


Bottom Gear Image