|
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
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. |
