W3C home > Mailing lists > Public > www-archive@w3.org > May 2004

Status report on metaDatInURI-31.

From: Williams, Stuart <skw@hp.com>
Date: Thu, 6 May 2004 16:07:47 +0100
Message-ID: <E864E95CB35C1C46B72FEA0626A2E808031A8FD9@0-mail-br1.hpl.hp.com>
To: tag@w3.org
Cc: www-archive@w3.org

Since I won't be there next week and there is an agenda item to report on
status of findings in progress, here's my update wrt to metaDataInURI-31 -
Cc'd to www-archive so that the meeting record can make public reference as
appropriate.

I did set out with the best of intentions to revise the finding in response
to comments received so far, unfortunately, I have yet to make any revisions
and apologise to the TAG for failing to do so. However, I did make a start
at the pre-work of reviewing all the comments we receieved on the current
draft, and managed to pull out single sentence summaries (mainly) of each
comment. The next step is to got through that list and decide how to address
them (which I have not yet done) - there a small number of comments faced in
opposing directions - eg. DO peek;  DON'T peek; and "DON'T peek is too
simplistic".

Have a good meeting. Sorry I cannot attend.

Regards

Stuart
--

Summary of comments on metadataInURI-31 draft finding:
------------------------------------------------------

Original question: "Should there be a standard way of embedding metadata in
URI"; Answer NO.
Norm: http://lists.w3.org/Archives/Public/www-tag/2003Jul/0048.html

Embedding metadata is ok... extraction may be more problematic:
Norm: http://lists.w3.org/Archives/Public/www-tag/2003Jul/0048.html


Editorials:
----------
Norm: http://lists.w3.org/Archives/Member/tag/2003Jul/0023.html

Technical comment on .ca domain example:
---------------------------------------
Mark Baker: http://lists.w3.org/Archives/Public/www-tag/2003Jul/0041.html

Size of Finding:
----------------
  Says too much: 
     Tim Bray: http://lists.w3.org/Archives/Member/tag/2003Jul/0030.html
     Mark Nottingham:
http://lists.w3.org/Archives/Public/www-tag/2003Aug/0048.html
     Oliver Fehr:
http://lists.w3.org/Archives/Public/www-tag/2003Sep/0196.html
     TAG (someof):
http://www.w3.org/2003/07/21-tag-summary.html#metadataInURI-31

  Keep sections 2 and 3:
     Mark Baker:
http://lists.w3.org/Archives/Public/www-tag/2003Jul/0041.html
     Noah Mendelsohn:
http://lists.w3.org/Archives/Public/www-tag/2003Aug/0055.html
     TAG (someof):
http://www.w3.org/2003/07/21-tag-summary.html#metadataInURI-31

Bring some of the more important points forward:
------------------------------------------------
Noah Mendelsohn:
http://lists.w3.org/Archives/Public/www-tag/2003Aug/0055.html
Mark Nottingham:
http://lists.w3.org/Archives/Public/www-tag/2003Aug/0056.html

Embed metadata, DO peek inside:
-------------------------------
Michael Daconta:
http://lists.w3.org/Archives/Public/www-tag/2003Jul/0037.html
Michael Daconta:
http://lists.w3.org/Archives/Public/www-tag/2003Jul/0067.html

Embed metadata: DON'T peek:
---------------------------
Patrick Stickler:
http://lists.w3.org/Archives/Public/www-tag/2003Jul/0039.html
Paul Prescod: http://lists.w3.org/Archives/Public/www-tag/2003Jul/0043.html
Norm: http://lists.w3.org/Archives/Public/www-tag/2003Jul/0065.html
Norm: http://lists.w3.org/Archives/Public/www-tag/2003Jul/0068.html
Len Bullard: http://lists.w3.org/Archives/Public/www-tag/2003Jul/0066.html
Patrick: http://lists.w3.org/Archives/Public/www-tag/2003Jul/0071.html

Embed static characteristics only:
----------------------------------
Patrick Stickler:
http://lists.w3.org/Archives/Public/www-tag/2003Jul/0039.html
Michael Daconta:
http://lists.w3.org/Archives/Public/www-tag/2003Jul/0045.html

There are better ways of getting resource metadata:
---------------------------------------------------
Patrick Stickler:
http://lists.w3.org/Archives/Public/www-tag/2003Jul/0039.html

REST "hypermedia as the engine of application state" of relevance:
------------------------------------------------------------------
Mark Baker: http://lists.w3.org/Archives/Public/www-tag/2003Jul/0041.html
Mark Baker: http://lists.w3.org/Archives/Public/www-tag/2003Jul/0099.html
Stuart (understands):
http://lists.w3.org/Archives/Public/www-tag/2003Jul/0101.html

Some URI scheme specs do seem to try to constraint the sort of referenced
resource:
----------------------------------------------------------------------------
-------
Stuart: http://lists.w3.org/Archives/Public/www-tag/2003Jul/0091.html

Sort of resource unconstrained by URI scheme (indirect indentification):
------------------------------------------------------------------------
Mark Baker: http://lists.w3.org/Archives/Public/www-tag/2003Jul/0041.html

Just "Don't Peek" is too simplistic:
------------------------------------
Stuart: http://lists.w3.org/Archives/Public/www-tag/2003Jul/0040.html
Patrick: http://lists.w3.org/Archives/Public/www-tag/2003Jul/0055.html (but
don't peek - generally)
Stuart: http://lists.w3.org/Archives/Public/www-tag/2003Jul/0080.html
Partick (middle ground):
http://lists.w3.org/Archives/Public/www-tag/2003Jul/0123.html
Mark Nottingham:
http://lists.w3.org/Archives/Public/www-tag/2003Aug/0048.html

Syntactic understanding is not peeking:
---------------------------------------
Norm: http://lists.w3.org/Archives/Public/www-tag/2003Jul/0086.html

Truely opaque URI;
-----------------
syntactic conventions about schemes and #s would require rework of existing
specs.:
Jonathan Borden:
http://lists.w3.org/Archives/Public/www-tag/2003Jul/0133.html

Robustness prinicple applied to URI:
------------------------------------
Norm: http://lists.w3.org/Archives/Public/www-tag/2003Jul/0095.html
Stuart(some appeal):
http://lists.w3.org/Archives/Public/www-tag/2003Jul/0100.html
Mark Baker (disagrees):
http://lists.w3.org/Archives/Public/www-tag/2003Jul/0104.html

Identity and Identification...don't get confused:
-------------------------------------------------
Roy: http://lists.w3.org/Archives/Public/www-tag/2003Jul/0102.html
Stuart: http://lists.w3.org/Archives/Public/www-tag/2003Jul/0103.html

Indirect reference and context of use:
--------------------------------------
Roy: http://lists.w3.org/Archives/Public/www-tag/2003Jul/0105.html
Stuart (agreeing):
http://lists.w3.org/Archives/Public/www-tag/2003Jul/0108.html

Identifiers and Identification are related (inherently):
--------------------------------------------------------
Len Bullard: http://lists.w3.org/Archives/Public/www-tag/2003Jul/0106.html
Len: http://lists.w3.org/Archives/Public/www-tag/2003Jul/0107.html

Re: sec 3.3 ednote: 
-------------------
Query responses rarely cached, URI treated as opaque if they are:
Mark Nottingham:
http://lists.w3.org/Archives/Public/www-tag/2003Aug/0048.html

Target some of the comments at 'agent' implementers and spec writers:
---------------------------------------------------------------------
Mark Nottingham:
http://lists.w3.org/Archives/Public/www-tag/2003Aug/0048.html
Mark Nottingham:
http://lists.w3.org/Archives/Public/www-tag/2003Aug/0056.html

Notion of Authority is 'overplayed' Most URI scheme defn's are operational:
---------------------------------------------------------------------------
Larry Masinter:
http://lists.w3.org/Archives/Public/www-tag/2003Sep/0192.html
Stuart: http://lists.w3.org/Archives/Public/www-tag/2003Sep/0193.html

Assignment, interpretation on receipt and intention when making reference
are different things.
The finding is more about the last two which is separate from the
association of a resource with an identifier.
Larry: http://lists.w3.org/Archives/Public/www-tag/2003Sep/0213.html

Operationalise: Think operationally.
------------------------------------
Larry (off-list correspondence).

Separate URI assignment from attributions of meaning:
-----------------------------------------------------
Larry (off-list correspondence)

Forms as server supplied specifications for URI query construction.
------------------------------------------------------------------
Larry (offlist correspondence)
David Orchard (offlist correspondence).

TAG July F2F Comments:
http://www.w3.org/2003/07/21-tag-summary.html#metadataInURI-31
TB,DC,DO proposal: just section 1 plus examples inc. 
 - what format spec. designers can do. (DO)
 - Give an example of a relative normative spec that is providing policies
for looking within the URI.  (RF)
 - add a a mention that fragid needs mime type in 3.4 (TBL)
 - Section 1.1, part one - We need an example. (RF)
 - possibly merge sections 2 and 3 into a URI component centric view. (SKW)
 - Need to be clear that 'authority' propagates through specs. (TBL)
Received on Thursday, 6 May 2004 11:08:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 7 November 2012 14:17:44 GMT