W3C home > Mailing lists > Public > www-tag@w3.org > October 2005

endPointRefs-47

From: David Orchard <dorchard@bea.com>
Date: Tue, 4 Oct 2005 09:28:14 -0700
Message-ID: <32D5845A745BFB429CBDBADA57CD41AF136402CE@ussjex01.amer.bea.com>
To: <www-tag@w3.org>
I'm troubled by the rough consensus on issue 47, as documented in [1].

 

Roughly summarizing, I believe that the W3C has not provided sufficient
technology for users to follow the advice, the TAG has not detailed
what, if anything, the WS-Addressing working group should do with this
advice, the central issue of stateful resources is broader than just Web
services, and that ignoring the widespread use stateful resources poses
the hazard that the TAG will be ignored and ineffective.  I believe the
TAG should do one or more of: 1) close the issue with no action; 2)
Provide a more suitable discussion of stateful resources and
identification of such with URIs; 3) Recommend that additional
technology to follow the advice is necessary.

 

I believe that the W3C XML, Web and Web services architecture are
inconsistent with respect to resource identification of XML based
resources.  The central design point of Reference parameters is to
enable XML QNames to be used by services and sent by clients, ala HTTP
Cookies with HTTP Session ids.  I observe that the W3C is the body where
standardization of the necessary XML and Web services technology is
occurring. The W3C does not provide a sufficient architecture that
enables similar functionality using URIs.   The EPR minter that does
want identifiers in EPRs does not have access to sufficient technology
from the W3C to enable them to follow the "use URIs" advice.  There are
a large variety of potential full and partial solutions available and I
believe the TAG should examine these further if it wishes to continue
the advice in [1].  For example, the W3C does not provide any kind of
standard for mapping an XML QName to a URI for embedding within a URI.
Effectively, I think the TAG has moral hazard with this advice.  

 

I will note that the TAG to date has rarely advised the community that
there are missing technology pieces to enable greater adherence to the
Web architecture.  The TAG could be more proactive and suggest that
technology should be created to enable EPR minters and consumers to more
readily use and participate in the Web architecture.

 

I'm unclear on what the TAG would like the WS-Addressing working group
to do with this advice.  Should the WS-Addressing group invent
technology?  Should they create a Primer advising EPR minters?  Is this
just informative?  Is the Web services architecture really a part of Web
architecture?  I believe that this would cause confusion within the
WS-Addressing working group as there are some wide extremes of potential
actions that WS-Addressing could do yet they are not guided in this.

 

There are a variety of design decisions that affect the choice of using
identifiers outside of a URI, EPRs being one example and HTTP Cookies
with session IDs being another.   I believe that many of these design
decisions are valid and part of the deployed Web as we know it.  If the
TAG is going to push back on Ref Parameters as identifiers, I believe
that TAG should be consistent and do the same for all similar
technologies such as HTTP Cookies with session ids.  OR, the TAG should
examine what I believe is the central issue, that of identifiable
stateful resources.  

 

My final concern is that I believe that the TAG is ignoring widespread
reality - such as the use of http cookies - and that has the
commensurate risk that the TAG will be diminished in public perception
for offering less than helpful guidance.   I believe that the most
common use of EPR Reference Parameters is for resource identification,
and saying "don't do it that way" and being ignored by the community
does not help the TAG or consumers of W3C technologies.

 

Cheers,

Dave

 

[1] http://www.w3.org/2005/09/22-tagmem-minutes.html#item05
Received on Tuesday, 4 October 2005 16:28:28 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:37 GMT