- From: Williams, Stuart (HP Labs, Bristol) <skw@hp.com>
- Date: Wed, 26 Mar 2008 18:59:04 +0000
- To: "www-tag@w3.org" <www-tag@w3.org>
- CC: Leo Sauermann <leo.sauermann@dfki.de>, Richard Cyganiak <richard@cyganiak.de>
Draft minutes from the TAG telcon of 20th March 2008 are available for review at:
http://www.w3.org/2001/tag/2008/03/20-minutes
Plain textversion attached below.
Regards
Stuart Williams
--
Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England
=================================================================================
- DRAFT -
TAG Weekly
20 Mar 2008
[2]Agenda
[2] http://www.w3.org/2001/tag/2008/03/20-agenda
See also: [3]IRC log
[3] http://www.w3.org/2008/03/20-tagmem-irc
Attendees
Present
Tim_Berners-Lee, Henry_Thompson, Stuart_Williams,
Jonathan_Rees, Norman_Walsh, T.V._Raman, Ashok_Malhotra,
Leo_Sauermann, Richard_Cyganiak
Regrets
Noah_Mendelsohn, Dave_Orchard, Dan_Connolly
Chair
Stuart Williams
Scribe
Jonathan Rees
Contents
* [4]Topics
1. [5]httpRedirections-57 (ISSUE-57)
2. [6]abbreviateURI-56 (ISSUE-56)
* [7]Summary of Action Items
_________________________________________________________
<Stuart> Scribe: Jonathan Rees
<Stuart> scribenick: jar
<leobard> hi, joining chat for the momment, phoning in in 10
minutes...
stuart: we are expecting guests to talk about httpRedirections-57
... agenda accepted
... no objections or abstentions re minutes of 13 march
... next meeting 27 march. ashok to scribe
... noah regrets for 27 march
... approval of feb f2f minutes to be tabled pending completion of
all days
Resolution: Approve 13 March 2008 minutes at
[8]http://www.w3.org/2001/tag/2008/03/13-minutes
[8] http://www.w3.org/2001/tag/2008/03/13-minutes
Richard Cyganiak has joined the call
Leo is in IRC and is expected on the call
httpRedirections-57 (ISSUE-57)
stuart: Welcome Leo
... Hoping that today, we can see clear to the end of this document
... To discuss: diagram and conneg + redirection
leo: State of SWEO - finishing in 1 week, end of March. Cool URIs
has been in progress for 1 year. Must be published within 1 week, if
it's to be a note
... hoping for no feedback
... We received a big review from Tim in Feb, and changed the doc.
No ack yet.
<Stuart>
[9]http://lists.w3.org/Archives/Public/public-sweo-ig/2008Mar/0052.h
tml
[9] http://lists.w3.org/Archives/Public/public-sweo-ig/2008Mar/0052.html
Tim: 16th of March...
<leobard>
[10]https://gnowsis.opendfki.de/repos/gnowsis/papers/2006_11_concept
uri/html/cooluris_sweo_note.html#r303gendocument
[10] https://gnowsis.opendfki.de/repos/gnowsis/papers/2006_11_concepturi/html/cooluris_sweo_note.html#r303gendocument
leo: Tim's suggestion has been added as an alternative
Tim: It's important which one you should do
... we want generic documents when appropriate, and not when not
leo: Look at 4.3, second paragraph
... Do you suggest we remove 4.2 ?
<leobard> remove 4.2?
Tim: No, 4.2 is appropriate when the HTML has more information than
the RDF
<Stuart> Editorial question: should 4.2 have a more expansive
heading than "303 URI"?
Tim: If one is more powerful than the other, then it is a different
document & must have different URI
<timbl_> 303 URIs with documents with different information.
Tim: how about "redirects to documents with different information"
[scribe's possible inaccuracy in quoting tim]
Tim: Probably more common is HTML automatically generated from RDF
... When RDF has been scraped, then they're clearly different
... There's nothing about CN, is there.
Leo: CN near beginning, in 2.1, but not detailed
<leobard> link to q - qs plz?
tim: if html is from rdf, the rdf should be preferred
stuart: There was a Richard/Tim exchange [in IRC]
<timbl_> qs(rdf) > qs(html) if the html is generated from the html.
tim: crucial point was where we changed tabulator in with firefox,
which has a choice between html and rdf
... there is a loss when you generate html from rdf
... problems with rules like "if the client can take rdf, give it
rdf" (similarly html)
<Stuart> My concern is where this (qs/qc) can be fixed in time for
an LC publication tomorrow and a 1 week review cycle?
leo: Is this written down somewhere?
tim: No
(q / qs relates to CN algorithm - quality)
<timbl_> qs = the amount by whichhte qualty of this is presevced (1)
or degraded (<1)
(scribe having difficulty transcribing Tim)
leo: Can you give example of correct server behavior?
<timbl_> If the RDF is dscarped (lossily) from hte HTML, the q(rdf)
< q(html)
tim: Quality measure should take direction of scraping into account
(Tim explaining CN quality parameters using images as an example)
<timbl_>
[11]http://httpd.apache.org/docs/2.0/content-negotiation.html
[11] http://httpd.apache.org/docs/2.0/content-negotiation.html
<leobard> cygri sees a problem with server side of q-values, it
seems not specified
leo: The client/server quality interaction is not specified in
HTTP/1.0
... Apache does a particular thing, but this seems obscure
... This presents a problem for the document
... Nothing to cite
tim: Fair enough. Maybe explain what to do specifically for Apache
stuart: Maybe a simple reference to apache doc would help?
richard: Explain it in general terms - say that you should bias
[using quality params] in the right direction?
... Point to apache as one example
<timbl_> In the case in which for example an HTML file has been
generated from the RDF file, then the HTML has lost some
information, so the RDF should be deleivered for clients whcih
accept boethr RDF and HTML with similar q levels (see HTTP sec).
<timbl_> In the case in which the RDF file has only a subset of the
information in the HTML file, and teh client handles with, then the
server should have a preference for the HTML in the content
negotiation algortithm
<timbl_> See for example the Apache content negotiation [ref].
Tim: You can do it with typemap files, but not with multiviews.
Apache bug.
<timbl_> You can do this with a type-map file but not with
multiviews, as there are no qs specified in the config file for
multiviews
<leobard> the replaced diagram is here:
[12]https://gnowsis.opendfki.de/repos/gnowsis/papers/2006_11_concept
uri/html/cooluris_sweo_note.html#r303gendocument
[12] https://gnowsis.opendfki.de/repos/gnowsis/papers/2006_11_concepturi/html/cooluris_sweo_note.html#r303gendocument
stuart: What is the effect on the diagrams of this discussion?
<leobard> diagram:
[13]https://gnowsis.opendfki.de/repos/gnowsis/papers/2006_11_concept
uri/html/img20071212/303conneg.png
[13] https://gnowsis.opendfki.de/repos/gnowsis/papers/2006_11_concepturi/html/img20071212/303conneg.png
tim: It's simplistic about CN
<timbl_> "application/rdf+xml wins"?
richard: it should be changed
raman: Can you add a pointer to the tag finding i wrote last year?
[genericResources]
richard: yes
<cygri>
[14]http://www.w3.org/2001/tag/doc/alternatives-discovery.html
[14] http://www.w3.org/2001/tag/doc/alternatives-discovery.html
raman: in the section on generic resources
stuart: general agreement on switching 4.2 and 4.3
<leobard>
[15]https://gnowsis.opendfki.de/repos/gnowsis/papers/2006_11_concept
uri/html/cooluris_sweo_note.html#distinguishing
[15] https://gnowsis.opendfki.de/repos/gnowsis/papers/2006_11_concepturi/html/cooluris_sweo_note.html#distinguishing
tim: It's not a disinction between web documents and things. Web
documents *are* things
richard: but this is covered in the first sentence
raman: Too vague - strike it out
discussing 'err on the side of caution'
<Stuart> from my POV the httpRange-14 questions was "what kinds of
thing can be named with an http URI" and we said "...anything..."
even in the case where there is no '#' in the URI.
tim: end of 3.1 will confuse people.
<timbl_> It is not necessary to make that distinction, to define
from first priciples what a douemnt is or is not.
ht: Agree with the goal of this section - advise people when they
have a certain class of problems
... Everything would follow if section title were "URIs for things
not on the web"
<timbl_> You can say, "We have demonstrated how URIs can be given to
things, and to the documents about those things, and how they
connect".
tim: Doesn't have to be "real world objects"
ht: Need to judiciously change the rhetoric - we don't need to
descend into argument
richard: But this argument has been going on for 5 years
... There is a problem, I have something sitting in front of me, can
I return a 200 or not?
... The question [of what is an IR] matters
timbl: No one will think a telephone is a web document
jar: But is a representation a web document? Or the number 3?
<Stuart> jar... do you mean the number or a numeral?
ht: There are clear cases and hard cases
<cygri> seems i dropped from the call ... will rejoin
<raman> lots of static on the line
timbl: It's important that we not go there - questions like is 3 an
IR
<leobard> decision is needed on whether remove 3.1 or keep it
timbl: Propose 3.1 be removed
<timbl_> Note that URIs of people amd the documents abou them sould
not be confused: For example the person Alice is described on her in
an information resource, Alice's homepage. Bob may not like the look
of the homepage, but fancy the person Alice
<timbl_> +1 for remove 3.1
<ht> I'm happy with 3.1 as it stands, with one small modification
<ht> First sentence should be changed to "Above we assumed that
there is a distinction between web documents and everything else"
<ht> and similarly to the title of the section
<timbl_> as
ht: Thinks only one small change is needed - don't remove 3.1
... Only problem is "real world object"
... Summary is helpful
<timbl_> Note that URIs of people and the documents abou them sould
not be confused: For example the person Alice is described on her
homepage. Bob may not like the look of the homepage, but still like
the person Alice.
tim: "Not everything is a web document" - 303 is perfectly fine for
web documents
ht: Can I ask the authors, do you understand why we're opposed to
setting up an opposition between web documents and real world
objects?
yes
ht: Can you rewrite this? It's going to be too hard to redraft the
paragraph on this call
we've rewritten it 5 times already
timbl: 303 and # work in all cases, IR and non-IR
... non-IR is not an interesting category
<timbl_> Distinguishing between things and the web documents about
them.
<timbl_> We have discussed ways of giving URIs to all kinds of
things,
<timbl_> so that the client can find out the URIs of documents
between them.
<timbl_> Note that URIs of things, say people, amd the documents
abou them should not be confused: For example the person Alice is
described on her homepage. Bob may not like the look of the
homepage, but still like the person Alice.
author: To fix this would require a lot of changes, not just here
but throughout the document
... No time
stuart: Let's try Henry's suggestion
<ht> HST is sending Richard and Leo a suggested rewrite, copied to
www-tag
stuart: Tim, please review
<Norm> noah, could you take a look at the minutes I sent you for
review yesterday or the day before?
timbl: Getting the document is more important than perfecting it
stuart: Thanks for doing this. We all think it's a good document
CURIEs
abbreviateURI-56 (ISSUE-56)
<ht> [16]http://lists.w3.org/Archives/Member/tag/2008Mar/0069
[16] http://lists.w3.org/Archives/Member/tag/2008Mar/0069
<noah> Norm - did you take the edited HTML I sent you on 2/29, or
just rerun from the IRC log? Doing the latter is a real mistake. I
did quite a bit of editing on a private copy of the log, then
generated clean HTML. I >think< the text that's worrying you does
not show up in the clean copy.
i haven't been scribing. iw as talking
my question is how strongly tag should come down against union of
URI and [curie]
<timbl_> xml2? URI2?
noah: Would you be willing to commit to there never being a new URI
syntax beginning with [ ?
<Stuart> noah's question is targetted on the 'stewards' of the URI
spec.
<Zakim> ht, you wanted to suggest a change to point 3
ht: We're clearly talking about new context or new languages...
maybe this isn't explicit enough
... The square brackets don't address this problem. It's not up to
HTML 2 WG to say that URIs don't begin with [
noah: Have they redefined the syntax of URIs?
<Stuart> Norm.... pointer please to the transgression?
<timbl_> They have not redefined URI, but they are defining a
competing type which incldues URI and will only work if URI strings
never start with '['
raman: We need to create an environment where people can solve these
problems
norm: Then we should say yes
<Norm> raman's x:foo example is different from javascript:void. The
"x" isn't constant.
tim: Precedent: transition from URI to IRI.
<Stuart> see [17]http://www.w3.org/2006/07/SWD/RDFa/syntax/#id102419
[17] http://www.w3.org/2006/07/SWD/RDFa/syntax/#id102419
<Stuart> example text is:
<Stuart> "This document is licensed under a
<Stuart> <a
xmlns:cclicenses="[18]http://creativecommons.org/licenses/"
[18] http://creativecommons.org/licenses/
<Stuart> rel="cc:license"
<Stuart> href="[cclicenses:by/nc-nd/3.0/]">
<Stuart> Creative Commons License
<Stuart> </a>."
ouch.
<ht> Is that for HTML2 or XHTML 4.01?
tim: There's no way URIs will start with square brackets...
<Stuart> ht: don't know haven't read enought of the surrounding
context... but assume RDFa in XHTML2
tim: but that's not the problem. The problem is that as time goes on
all URI parsers will be expected to handle these things
<ht> If it's XHTML2, there's no problem -- they can define the
content of href in a new language however they like
<ht> the problem comes if they try to push this back into HTML4.01
raman: How is this different from ability to handle new uri schemes
(e.g. javascript:)?
<Norm> that's not a useful distinction, ht, even if its only spec'd
for xhtml2, if it's useful, it'll be back-formed into other specs
(I think raman is making the same comparison I did, of [...] to a
new URI scheme)
ht: Browsers all already have plugin-based URI scheme handling
... I don't think this is ready to send
<Norm> <a xmlns:http="[19]http://foo" href="[http:/bar]">bar?</a>
[19] http://foo/
ht: I hear a repeated willingness to engage constructively
<noah> IF we go down this path, I think a key question is whether we
suggest that existing formats MAY or SHOULD support CURIE | URI
ht: Let's ask them questions about exactly where they see this being
used and where not
noah: Key missing piece: we should point a direction (may, should)
ht: I disagree. This is a use for new contexts/languages going
forward
timbl: Not realistic
<Norm> +1 to timbl_
timbl: bad engineering
<noah> SOm Henry says "MAY
<Zakim> jar, you wanted to say that he thinks RDFa has been VERY
careful not to allow href="[...]"
<noah> SOm Henry says "MAY" and Tim says "SHOULD
<ht> No, Henry says MUST NOT change parsers to accept CURIEs where
existing W3C specs call for URIs
<Norm> Indeed, jar, 2.1 does seem to be clear along the lines you
suggest
<noah> Sorry to come late and then run, but I've got to go. Next
week I will NOT be on the call. Please accept my regrets for that.
<ht> ACTION: Henry S to post a redraft of comment (3) from
[20]http://lists.w3.org/Archives/Member/tag/2008Mar/0069 to
tag@w3.org [recorded in
[21]http://www.w3.org/2001/tag/2008/03/20-minutes.html#action01]
[20] http://lists.w3.org/Archives/Member/tag/2008Mar/0069
[21] http://www.w3.org/2001/tag/2008/03/20-minutes.html#action01
<trackbot-ng> Created ACTION-126 - S to post a redraft of comment
(3) from [22]http://lists.w3.org/Archives/Member/tag/2008Mar/0069 to
tag@w3.org [on Henry S. Thompson - due 2008-03-27].
[22] http://lists.w3.org/Archives/Member/tag/2008Mar/0069
Summary of Action Items
[NEW] ACTION: Henry S to post a redraft of comment (3) from
[23]http://lists.w3.org/Archives/Member/tag/2008Mar/0069 to
tag@w3.org [recorded in
[24]http://www.w3.org/2001/tag/2008/03/20-minutes.html#action01]
[23] http://lists.w3.org/Archives/Member/tag/2008Mar/0069
[24] http://www.w3.org/2001/tag/2008/03/20-minutes.html#action01
[End of minutes]
_________________________________________________________
Received on Wednesday, 26 March 2008 19:03:45 UTC