Hypertext and Web Services

David Orchard wrote:
> 
>...
>
> You dispute my recollection of history. so beit.  

The *current situtation* is that XLink is usable for general purpose
linking and in my experience, it is much more popular for linking in
situations that do not involve human-readable renditions of data. I
could list five clients that were using XLink before I walked in and
they were all using it for "data-oriented" applications. I could also
quote references like those below all day.

The user community has decided in that case that there is no substantive
distinction between "hypertext" and "data" or "data" and "documents".
Perhaps the user community is wiser than the working group. So beit.

============

 * http://www-106.ibm.com/developerworks/xml/library/x-xdxlnk/index.html

"This column takes a look at how to use XLink pointers when representing
data to make XML documents more compact and flexible. Sample code shows
examples of an invoice with and without the XLink pointers, plus an
example of using XLinks with a URL-addressable database."

Data Moddelling with Markup Languages:

 *
http://www.pms.informatik.uni-muenchen.de/forschung/datamodeling-markup.html

"This variety of hyperlinks is but one aspect of the richness of XML as
a data modeling formalism. Some of the hyperlink types are very simple
and convenient for expressing data sharing in complex structures, making
possible structures corresponding to graphs that are no trees. More
complex hyperlink types are primarily intended for browsing facilities,
but seem to be usable also for expressing semantic relationships."

 * http://www.labs.fujitsu.com/free/xlip/en/sample2.html

"Fujitsu has applied its Fujitsu XLink Processor (XLiP) in developing a
new technology to support XLink and Xpointer application to XBRL, and
this is the first almost complete implementation for XBRL Specification
2.0 in the world"

==========

>...
> The terminology difference is crucial because MikeC, myself and others
> assert that general application to application integration has different
> requirements than hypertext applications.

Hypertext (text with links/references) is a technological solution to a
problem, not a problem domain. It was never a given that hypertext would
be used for travel reservations or stock purchases. There was a problem,
hypertext was proposed as a solution and it worked. Now we have similar
problems, but we want computers to do the reserving and the purchasing.
We are again proposing hypertext as a solution. Please open your mind to
the possibility that it may have something to offer as a technology.

Five years ago, generic markup was considered a document-oriented
problem domain with no applicability to application to application
services either. There were a few crackpots[1] who proposed it as such,
but they could not get a hearing in the mainstream programming world.

[1]
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=414u6u%24nau%40hopper.acm.org

After all, markup was a problem domain, not a technology.

Then Microsoft embraced it as a *technology* that solved some tricky
problems in the A2A domain. All of a sudden everyone else piled on. Wow!
These document-heads had some useful ideas about representing
information in ways that allowed loose coupling of implementations!
Thirty years of research into loose coupling had paid off!

Now we're going through the whole thing again with links and hypertext.
Linking is the *other half* of the structured markup picture and it is
important for all of the same reasons that structured markup is
important: the ability to represent complex information, the ability to
allow the recipient to infer meaning rather than imposing behaviour
(loose coupling) etc. 

If you want to wait around for Microsoft to "get it" again, go ahead.
I'm hoping that this time it will take them not thirty years but three
years. Either way, anyone who waited will be years behind people who put
in the effort to understand up-front.

>...
> There's a big difference between humans using browsers to interact with an
> application versus an application interacting with an application.

There are some big differences. And there are some big similarities. I
admit that it takes effort to distinguish between them but the effort is
not wasted.

>...
> This extended debate is EXACTLY why I would like to have the harvesting task
> force focus on soap and wsdl.  The TAG has said that it is happy with SOAP
> 1.2 in the web architecture.  

SOAP 1.2 is explicitly designed to support links between resources
(hypertext). You'll recall that it earlier did not and great effort was
expended to correct the flaw. It would be a horrendous waste of effort
to now write that correction out of the architecture. 

> ... That is sufficient to indicate that SOAP 1.2
> fits into the web architecture, so SOAP 1.2 and WSDL should be sufficient
> for us to harvest to start a web services architecture.

SOAP and WSDL do not describe an architecture. They describe syntaxes. I
don't really know what there is there to harvest. Insofar as SOAP embeds
much of REST by reference, sure, harvest SOAP and from there go on to
harvest REST, URIs, hyperlinks and the rest of the Web architecture.

> ...  Developers have
> real problems with figuring out what the web services architecture is and
> how to use and extend it, and we're not addressing their needs by endlessly
> debating REST's utility.  We've probably blown our July deliverable schedule
> that we promised in June.

In too much of a hurry to look at the map?

-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/

Received on Thursday, 18 July 2002 10:07:13 UTC