Re: Hypertext and Web Services

+1 for the list!
On Thursday, July 18, 2002, at 09:14  AM, David Orchard wrote:

>
> 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 18:57:29 UTC