<Noah> scribenick: Noah
<scribe> scribe: Noah Mendelsohn
date: 30 August 2007
<scribe> scribenick: raman
<Noah> scribe: T.V. Raman
RESOLUTION: Approved minutes of the previous meeting http://www.w3.org/2001/tag/2007/08/20-minutes
Skipping URN Registries -- No HST
Password in the clear: Stuart has sent message to chairs asking if other WGs would like to meet with the TAG
<scribe> ACTION: STUART Send MEZ email asking for a joint meeting with the Security WGduring the Plenary [recorded in http://www.w3.org/2001/tag/2007/08/30-minutes#action01]
<trackbot-ng> Created ACTION-40 - Send MEZ email asking for a joint meeting with the Security WGduring the Plenary [on Stuart Williams - due 2007-09-06].
RESOLUTION: TAG calls will be at this time Thursday 10:00 PT13:00 ET going forward.
Logistics -- Organizers need Mac Address
<Stuart> Skeletal Draft Agenda at: http://www.w3.org/2001/tag/2007/09/17-agenda
<Stuart> Email suggesting and requesting agenda topics http://lists.w3.org/Archives/Member/tag/2007Aug/0038
<scribe> Done with F2F Agenda for now
Question for TimBL:Can we use http://www.w3.org/tag/blog as the uri of our blog
<timbl_> Yes we may
TimBL: Yes we may
<Stuart> Not holding Tim to first answer.
<Noah> Even if we decide on www.w3.org/tag/blog, we could still have www.w3.org/blogs be a page that gives links to lots of group's blogs
<scribe> ACTION: TimBL to investigate getting http://blog.w3.org/tag [recorded in http://www.w3.org/2001/tag/2007/08/30-minutes#action02]
<trackbot-ng> Created ACTION-41 - Investigate getting http://blog.w3.org/tag [on Tim Berners-Lee - due 2007-09-06].
<timbl_> I think http://www.w3.org/blog/TAG seems to the logical one
for the record, http://w3tag.blogspot.com is available.
Discuss follow-up from Norm's announcement of the new issue "Scalability of URI Access to Resources"
Norm would like some time next week or at the F2F
<Norm> There seem to be two aspects to the discussion that followed the announcement: some related to retreival and urnsRegistries; the other about authoratative representations (RDF you have from somewhere vs. the representation you get through GET.
<Noah> Sam Ruby's article is at: http://intertwingly.net/blog/2007/08/02/HTML5-and-Distributed-Extensibility
<Noah> It's really too bad that Dan isn't here for this discussion, suggest we discuss some now, then revisit when he's available.
<Noah> TVR: I'd be happy for Dave to send his note on behalf of the TAG
Stuart: wait for Dan
<scribe> ACTION: Stuart to check with Dan [recorded in http://www.w3.org/2001/tag/2007/08/30-minutes#action03]
<trackbot-ng> Created ACTION-42 - Check with Dan [on Stuart Williams - due 2007-09-06].
TimBL: simple confusion: non-informational resource used to mean "thing"
<Noah> We should remember that we do have a definition of information resource in AWWW
<Noah> From AWWW:
<Noah> "By design a URI identifies one resource. We do not limit the scope of what might be a resource. The term "resource" is used in a general sense for whatever might be identified by a URI. It is conventional on the hypertext Web to describe Web pages, images, product catalogs, etc. as “resources”.
<Noah> The distinguishing characteristic of these resources is that all of their essential characteristics can be conveyed in a message. We identify this set as “information resources.”
stuart: there are entities that fit the definition of "information resource" that are not web accessible
<timbl_> There is no reason that something being an IR means it must be on the web.
Noah: single resource, 2 URIs -- one could return a 303
<timbl_> That will cause a fetch of foo.rdf whcih describes foo.rdf#peoem
<Noah> NM: With the obvious media type?
<Noah> TBL: Yes.
<timbl_> That 303s to ttp://exa,ple.com/thingsILike/poems.rdf which has stuff about it
<timbl_> and I might ahve a
<timbl_> version which has a repreentation and doe s a 200
<timbl_> All thse can be owl:sameAs each other
<timbl_> Example to show: 303 does not mean a non-infortaaion resource
<Noah> NM: Yes, strongly agree (except perhaps that my knowledge of the nuances of owl:sameAs is sufficiently limited that I can only assume that bit's right too)
<scribe> ACTION: TimBL Find the paper that he annotated on the plane [recorded in http://www.w3.org/2001/tag/2007/08/30-minutes#action04]
<trackbot-ng> Created ACTION-43 - Find the paper that he annotated on the plane [on Tim Berners-Lee - due 2007-09-06].
Stuart: discussion on redirection 57?
All to look at RL's draft
<edit> scribenick: Noah
TVR: Retrieve this page, you get HTML, but there are no IDs in the page that match.
... Without indicating whether I think this is good or bad practice. They take out the fragid and cons up a new URL that references a piece of a video stream.
... With text/html, they are doing that "ilk" of processing on the client.
... using # syntax and fragids.
... Is it time to document this, and explore interoperability questions?
... Depending on your view of the media type spec. for text/html, the semantics of fragids are either very loosely or very narrowly defined.
TBL: architecturally, when you have e.g. a fragid being passed to a script, that's a different architecture and perhaps the fragid should be viewed as opaque
... the normal case is that it
... the normal case is that it's transparent in the sense that most everyone knows how to interpret it.
TVR: Note that it conses up another URI.
TBL: Inside the script?
TVR: Interesting question. The script is calling the media player with that newly munged URI. You'll see the other URL there.
DO: This is a URI mapping algorithm
NM: Right, so a media typed representation was returned. The spec for that media type either does or doesn't allow for this interpretation of the fragid. Specifically as a question of web arch: I don't swe why the question is any bigger than "if this is going to be legal, then the media type spec needs to bupdated"
<Rhys> I tend to agree with Noah, that this looks like a question of what the rules are for text/html fragment ids
TVR: If that's the interpretation, we shouldn't be trading URLs with fragids if you don't know the rep
Web arch on fragid semantics is at: http://www.w3.org/TR/webarch/#media-type-fragid
From: The semantics of a fragment identifier are defined by the set of representations that might result from a retrieval action on the primary resource. The fragment's format and resolution are therefore dependent on the type of a potentially retrieved representation, even though such a retrieval is only performed if the URI is dereferenced.
If no such representation exists, then the semantics of the fragment are considered unknown and, effectively, unconstrained. Fragment identifier semantics are orthogonal to URI schemes and thus cannot be redefined by URI scheme specifications.
3.2.2. Fragment identifiers and content negotiation
I find it a bit frustrating that we're discussing this without first reading over what we've already written on this, which is in 3.2.2 of Web Arch. I agree with Norm it's unfortunately slippery, but we have said a lot about it.
"Consider an example where the owner of the URI "http://weather.example.com/oaxaca/map#zicatela" uses content negotiation to serve two representations of the identified resource. Three situations can arise:
1. The interpretation of "zicatela" is defined consistently by both data format specifications. The representation provider decides when definitions of fragment identifier semantics are are sufficiently consistent.
2. The interpretation of "zicatela" is defined inconsistently by the data format specifications.
3. The interpretation of "zicatela" is defined in one data format specification but not the other.
The first situation—consistent semantics—poses no problem.
The second case is a server management error: representation providers must not use content negotiation to serve representation formats that have inconsistent fragment identifier semantics. This situation also leads to URI collision (§2.2.1).
The third case is not a server management error. It is a means by which the Web can grow.
TVR: OK, I didn't know we'd ruled on that.
<Stuart> from RFC 2854 text/html media type registration:
<Stuart> 3. Fragment Identifiers
<Stuart> The URI specification [URI] notes that the semantics of a fragment
<Stuart> identifier (part of a URI after a "#") is a property of the data
<Stuart> resulting from a retrieval action, and that the format and
<Stuart> interpretation of fragment identifiers is dependent on the media type
TVR: I think at very least, the fragid specification for the HTML media type should be revisited
<Stuart> of the retrieval result.
<Stuart> For documents labeled as text/html, the fragment identifier
<Stuart> designates the correspondingly named element; any element may be
<Stuart> named with the "id" attribute, and A, APPLET, FRAME, IFRAME, IMG and
<Stuart> MAP elements may be named with a "name" attribute. This is described
<Stuart> in detail in [HTML40] section 12.
Right, which is why I asked from the start why this isn't mainly a question of that media type specification.
<timbl_> #raman #intro #alert
<timbl_> person, para, js fun
TBL: I'm worried about mixed namespace documents, and the risk we'd head down the road of having the same fragid be both a person and a paragraph. I don't want to go there.
<timbl_> Either the anchor namespace and people namespaces are separate or they are overlayed.
<timbl_> i think in this case with xml ns miing we have a dociument-wide namepscem,so they must be overlayed, so an id must not be used to identify both aan anchor and a paragraph