RE: Hypertext and Web Services

Paul,

I don't think there's much point to further debate about xlink's
applicability to general xml processing.  It certainly can be used as such.
Unfortunately, it's not that great at either general xml processing or
hypertext processing.  The fact that Semantic Web, RDF, XHTML, XQuery, XSL,
etc. do not use XLink is telling.  The applicability of xlink is TAG issue
23 http://www.w3.org/2001/tag/ilist#xlinkScope-23.  And TimBL's opinion says
that XLink is for hypertext only, http://www.w3.org/DesignIssues/XLink.html,
and even restated my assessment that xlink is for hypertext linking.  The
relevence of this point is that even TimBL sees differences between
hypertext - user to machine interactions - and other application to
application interactions.  Perhaps we should simply agree to disagree.

SOAP 1.2 and WSDL are not just syntaxes, they are also contain many
architectural elements.  And they are the foundational architecture elements
for web services.  There are things like the soap processing model, the
message exchange pattern descriptions, the transport binding framework, etc.
that are all important architectural components.  But we probably simply
need to agree to disagree on this as well.

It's not a case of too busy to read the map, it's that when I want to read
my roadmap, somebody puts a topographic map over it and says I don't need
roads at all because there are rivers all over the topo map.  Roadmaps are
certainly guided by topography, but at the end of the day I've got a car and
not a canoe.

Cheers,
Dave


> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Paul Prescod
> Sent: Thursday, July 18, 2002 7:06 AM
> To: David Orchard; www-ws-arch@w3.org
> Subject: 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/datamodeli
> ng-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 12:16:07 UTC