RE: TAG Architecture Draft

Mike,

I'd really like to discuss this, at least at the level of finding out how we could get our comments and questions addressed.  For example, I do not see anything in the draft that pertains directly to Web services, and therefore my first question is whether or not Web services are considered part of the Web architecture.  If not, that would certainly clear up a lot of things.  If so, we could start some joint work to see how best to fit Web services into the document.

Eric

Comments/questions on the 30 August Draft, Architectural Principles of the World Wide Web

General question:  Should this spec include Web services? In other words, are Web services considered part of the Web Architecture?  Or are Web services considered a completely different, unrelated architecture?  If so perhaps we should consider renaming them?  (Internet Services or something?)  

General comment:  The document is unclear on the question of whether the Web consists of resources referring to one another, of agents referring to resources, or of agents referring to one another.  It is also not entirely clear whether agents that are programs can link to  each other through a resource.  A resource is defined as services, people, organizations, and concepts (section 2) but it isn't clear whether a resource can be an agent or a program, or a way for agents to refer to each other.  The document defines the fundamental building blocks of Web architecture, which seems to consist primarily of agents and resources, but it isn't completely clear what the relationship of agent/programs are to other programs, or of resources to agents/programs that may want to link through resources.

Specific comments:

Section 1 -- agents are defined as programs acting on behalf of another person, entity, or process, but not on behalf of other programs.  Is this relationship out of scope or just not defined?  (i.e. agent-agent)

-- Is XML not a data format?  Perhaps strictly speaking it's a language for defining other languages, but in practice isn't it often used as a data format?  (I am relatively new to XML so I may not be understanding correctly.)

Section 2 -- are Web services resources?  A resource is identified to include "documents, files, menu items, machines, and services, as well as people, organizations, and concepts."  What about programs and/or agents?  It's hard to tell whether the definition is intended to encompass them or exclude them.  Web services could be included as either documents or services, I suppose.

-- examples do not include any mention of Web services, should they?

-- the question of how fragment identifiers relate to Web services is interesting, as they could potentially refer to individual services or operations within a list of services or operations...

Section 2.1 -- States that "one resource refers to another...the large-scale effect is a shared information space" but earlier text mentioned agents as the things that exchange  information.  How do agents relate to resources, if resources refer to one another to create the information space?  Is what's really meant that agents refer to resources to link information, and therefore does it follow that agents can link to agents also (possibly through resources?)

-- interesting comment that searching is "serendipitous" -- I understand this wasn't part of the Web by design, and more of a side effect of unique URIs.  But what about Web services? Aren't they also "serendipitous" occurrences?

-- Could a middleware system be a software agent?  Or a database management system?  Or an ERP or CRM system?

Section 2.2.2 -- comment: dereference semantics sound a lot like dequeue semantics in message queueing middleware systems

-- Would it be helpful to include an example of an interaction with an XML resource, perhaps one that could be linked to a Web service, or similar?  Perhaps an example of an XML resource mapped to a software agent such as a middleware queueing system (that does the dereference and an enqueue?)

-- Perhaps a more fundamental question is whether a Web service is a resource?

-- Doesn't this discussion about URN schemes indicate that URLs are really the only things that make sense for dereferencing resources?

-- It's not clear what "obligation" means in the context of "a user does not incur an obligation by following an HTML link that causes the user agent to retrieve a representation."  Perhaps this is explained in another document, in which case a reference would be helpful.

-- Also the qualifier "user" on agent seems to indicate (as other examples and references throughout the architecture do) that the architecture is centered around rendering documents for users.  Is that correct?

-- Is it correct to conclude from the URI discussion that it is not recommended to use the same URL to GET a WSDL file and also refer to the Web services endpoint in a subsequent POST?

Section 2.2.4 -- the context sensitive nature of state retrieval is clear enough as a concept, but the precise mechanism for determining user identity, geographical information, etc. isn't clear -- unless I'm missing something, which is of course entirely possible ;-) but if so adding a reference to where these things are defined would be helpful.

-- Context sensitivity in URI absolute references would seem to defeat interoperability...? (assuming Web services could be resources I guess)

-- "equivalent" with repsect to URI consistency, is that similar to the problem space addressed by XML info set, or canonical XML?

Section 2.5 -- do fragment identifiers apply to Web services?  It's defined here as a hypertext anchor...

Section 3.3 -- how about adding an issue around whether or not Web services are part of Web architecture?

Section 4.1 -- Client/server model -- what about a case in which there's no rendering? i.e. only processing?  (this may assume of course that agents can refer to agents, and that agents are programs that can talk to each other, at least indirectly through linked resources)

-- Caching -- can no caching be forced? i.e. caching is allowed, but can it be prevented?

-- Uniform interface -- the term "components" is used but I could not find a definition of the term -- also, would be good to relate the term to agents and programs

-- general comment -- stateless interactions is common to middleware software systems, meaning perhaps they are viable candidates for agents?

-- the role of components is defined but again not the components themselves.  Is it a fair statement to conclude that a resource or agent discovers the programs to which Web services are mapped?  (i.e. that would preserve the hiding principle)

-- "hypertext" is used as the typical system example once again, and examples are given of rendering but not what I would call "processing" or "mapping" to programs -- in other words are there comparable cases for Web services in which rendering = mapping to web services implementations?  If not, should there be?

References -- no references to Web services, should some be added (of course this brings up the fundamental issue again)?

-----Original Message-----
From: Champion, Mike [mailto:Mike.Champion@softwareag-usa.com]
Sent: Friday, September 06, 2002 8:15 AM
To: www-ws-arch@w3.org
Subject: TAG Architecture Draft



Sorry to repeat this message, but I don't want it to get lost in the reading
list thread:

That W3C Technical Architecture Group has released its first official draft
of Architectural Principles of the World Wide Web [1].  It is obviously
relevant to the WSA, and while no formal reponse from the WSA WG has been
requested, we should read it, discuss it, consider how to align with it, and
push back on anything that is incompatible with our view of the Web Services
Architecture.

I'm not sure whether it needs a specific slot on the F2F agenda (advice
solicited!) but it should be considered required reading, and is likely to
come up in several contexts.

Excerpts:

'Abstract

The World Wide Web is a networked information system. Web Architecture is
the set of principles that all agents in the system follow to create the
large-scale effect of a shared information space. Identification, data
formats, and protocols are the main technical components of Web
Architecture, but the large-scale effect depends on social behavior as well.

This document strives to establish a reference set of principles for Web
architecture.

Status of this document

This section describes the status of this document at the time of its
publication. Other documents may supersede this document. The latest status
of this document series is maintained at the W3C.

This is the first public Working Draft of "Architectural Principles of the
World Wide Web." This document has been developed by W3C's Technical
Architecture Group (TAG) (charter).

This draft represents substantial input from TAG participants, but does not
yet represent consensus. It is also incomplete; sections 1 and 2 are the
most developed, 3 and 4 the least. The TAG has published a number of
findings that address specific architecture issues. Parts of those findings
may appear in subsequent drafts. Please also consult the list of issues
under consideration by the TAG.

Publication as a Working Draft does not imply endorsement by the W3C
Membership. This is a draft document and may be updated, replaced or
obsoleted by other documents at any time. It is inappropriate to cite this
document as other than "work in progress."

The latest information regarding patent disclosures related to this document
is available on the Web. As of this publication, there are no disclosures.

Please send comments on this document to the public W3C TAG mailing list
www-tag@w3.org (archive).'

[1] http://www.w3.org/TR/webarch/

Received on Monday, 9 September 2002 00:11:09 UTC