See also: IRC log
<scribe> Scribe: EdRice
Next teleconference June 6, 2006
<DanC> 6Jun OK by me
Scribe for next teleconference: Dave
<DanC> (these? http://lists.w3.org/Archives/Public/www-tag/2006May/att-0047/TAG_Minutes_May_16__2006.html )
Approve minutes of last teleconference
RESOLUTION: minutes linked from the agenda are approved.
Agenda approved as is.
The current agenda is at; http://www.w3.org/2001/tag/2006/06/12-agenda.html
Vincent, in section 4 we'll need reviewers for each document.
T.V. will finish creating content by the end of this week. So we'll have one week for discussion before face to face.
ACTION: Dave, Norm and Dan as reviewers for T.V.'s document. State in Web application design [recorded in http://www.w3.org/2006/05/30-tagmem-minutes.html#action01]
Passwords in the clear. Ed to provide first version soon; goal is next Tuesday.
Dan would review if short.
ACTION: Dan + Vincent to review for f2f [recorded in http://www.w3.org/2006/05/30-tagmem-minutes.html#action03]
<DanC> ok, I'll try to review passwords-in-the-clear, though I'll probably subcontract it.
State finding..
ACTION: Ed, Noah and Norm to review state finding. [recorded in http://www.w3.org/2006/05/30-tagmem-minutes.html#action04]
Vincent.. ok, that's it for the documents we should review for the f2f
any other topics or documents for our f2f?
<DanC> 2006/04/25 12:58:37 http://www.w3.org/2001/tag/doc/URNsAndRegistries-50.xml
<DanC> <- http://www.w3.org/2001/tag/findings
<scribe> ACTION: Dan, Ed to reivew URNsAndRegistries-50.xml [recorded in http://www.w3.org/2006/05/30-tagmem-minutes.html#action05]
<DanC> action -2
<DanC> Dan's action to review TV on versioning is withdrawn
TOPIC metadataInURI-31 issue
<noah> I have forwarded Raman's comments, and my response, to the public list. See: http://lists.w3.org/Archives/Public/www-tag/2006May/0052.html
T.V. comments;
T.V. I personally believe this document should be differentiating between humans and software.
<DanC> TimBL: I agree [with which? that the document should distinguish humans from software?]
Ed: Dont agree. If we're going to keep human readable documents as a basis, then the differance between human readable and software readable shouldnt be called out.
<dorchard> q to talk about WSDL 2.0 URI and HTML FORM URI construction
<Zakim> timbl, you wanted to say that when a human gueses, they use all the shrewdness which humans have, and take the consequences; when sojfwtare is written to guess, then it is written
Tibl: when you write software you etch into stone the methods.
<dorchard> disagree that it's stone. It becomes a versioning issue
Timbl: unless its specifically mandated by protocols, then any form of reading uri's is a bad idea.
<dorchard> how to version from V1 to V2 of URI "algorithm"
T.V. when a human guesses and knows he guessed he knows the consiquences. Its a problem when he shares that guess.
Noah: we need to distinguish
between software and a memo..
... I'm not convinced that software guessing is wrong all the
time.
David: One of the points I wanted to make; This whole issue of a URI cast into stone as soon as a piece of software is written for it.
DO: The WSDL 2.0 HTTP binding
takes a schema type and mapes it into a URI
... as soon as the software is written it has to have some
knowledge of the software for which its written. As soon as
that changes it becomes a versioning issue.
... the versioning finding doesnt go into that in too much
detail, but I did want to remind people that algarithams could
be built.
<noah> Is the downside of encoding this in software not well covered by the GPN that says: "Good Practice: Guess information from URIs only when the consequences of an incorrect guess are acceptable."
<noah> Why doesn't this cover the concern about software?
<dorchard> And add that versioning for forwards/backwards compatibility can be done.
timbl: I wanted to push back.. we
should ask computers to do those things that use logic and a
clean architecture/design.
... The first order of URI is that you dont need to look inside
(its opaque).
<noah> Constraint: Users of the Web and Web software MUST NOT attempt to draw unverifiable conclusions about a resource or its representations by inspection of its URI, except as licensed by relevant normative specifications or by URI assignment policies published by the relevant URI assignment authority.
<DanC> (is any of the boxes in http://www.w3.org/2001/tag/doc/metaDataInURI-31 most relevant to TV's comments? I'd like this discussion to be more grounded in text in the document)
timbl: I'm pushing back on what Noah was saying. Machines should not guess that .html is an .html file.
<dorchard> machines can guess HTML FORM parameters from a URI.
<DanC> (I presume timbl is talking about clients, not servers, when he says they shouldn't map .html to text/html . Clearly servers do this to great benefit)
<timbl> q!!!
DO: Tim, we already have the case where you can guess data from a URI.
Timbl: its written in the spec?
Do: yes
Timbl: that's different, that's not guessing, its written in the spec.
Noah: I think what I said was
in-between. It should not in all cases be prohibited
from.
... I think where we're going with this is that Tim heard me
saying something much stronger than I intended to say.
<noah> "Constraint: Users of the Web and Web software MUST NOT attempt to draw unverifiable conclusions about a resource or its representations by inspection of its URI, except as licensed by relevant normative specifications or by URI assignment policies published by the relevant URI assignment authority."
What I'd really like to say is that I don't think we need to bring this up in the finding any more than it is.
The first story in the finding ends in a constraint (not good practice).
Constraint: Users of the Web and Web software MUST NOT attempt to draw unverifiable conclusions about a resource or its representations by inspection of its URI, except as licensed by relevant normative specifications or by URI assignment policies published by the relevant URI assignment authority.
<noah> "Good Practice: Guess information from URIs only when the consequences of an incorrect guess are acceptable."
Noah: The second story then tells the story about a human guessing..
Good Practice: Guess information from URIs only when the consequences of an incorrect guess are acceptable.
Noah: I think this deals with the situation where I'm tempted to distribute the software because its specifically covered in the 'must not' in the finding.
<dorchard> Noah, that seems fairly reasonable and unifies the software/human perspectives.
<noah> "Good Practice: URIs intended for direct use by people should be easy to understand, and should be suggestive of the resource actually named."
<dorchard> software just might guess wrong a lot more if there's an incompatible change to the algorithm
<dorchard> q!!!
DO: I think I get where Noah is going.
<noah> Noah's main point is not to slice it by human vs. software, but by the nature of the consequence for a bad guess. The fact that software tends to incur unacceptable consequences is true, but is covered.
DO: I think the chances of someone not getting what they expect may happen a lot more often in a piece of software.
<Vincent> ack :)
DO: I think I need to touch on
this in the URL vs Registries issue. Its touched on a little
bit there.
... I thought it was a good point that URI's intended by use by
people should be easy to understand.
<noah> Would it help to mention that the MUST NOT is particularly susceptible to violation in the case that assumptions are baked into software? That would be fine with me.
<noah> I do think it is possible to write software that is safe in some cases. E.g. I guess in software that .xml is an XML file, but check the returned media type to be sure. That's OK, right?
timbl: I think that yes, Noah if you say everything is fine and you've done it yourself then you can do it.
<dorchard> DO: one suggestion for combining people/machines is to say URIs intended for parsing by an entity should be easy to understand by that entity - beit people or software.
timbl: However, in the architecture I think we should call out whats architecture and what we're encouraging people do it.
Noah: I understand what your
saying. I agree with much of what your saying. What I'm
confused about is that if you looked at part 1&2 of the
finding, how would you change it?
... It never shows an example of software guessing.
Timbl: I think the discussions is 'should we' add a point that says dont write software to do this.
Noah: I think it already says
that.
... it states that Martin's browser is in error for doing
this.
<DanC> (agree with what?)
timbl: I think we should say specifically in 2.2 'don't guess with software'
Noah: If others agree.. I could
do that.
... So 2.1 is ok?
Timbl: Yes
Noah: The earliest I could do
another draft is just before the f2f.
... I'd rather not commit it for our f2f but best
effort.
ACTION: Noah to produce new version of this document [recorded in http://www.w3.org/2006/05/30-tagmem-minutes.html#action06]
<Noah> ACTION 6=Noah to produce new draft for metaDataInURI-31
Vincent: I wanted to follow-up
and see if this panel discussion was a good idea.
... also, is there technically something we've learned there
that should be on our agenda.
Dan: Tim and I offered Misha some TAG time.
Vincent: Should I send him an email inviting him to a teleconference.
Dan: some sense you should.. some sense I should..
Timbl: We did give Misha some options on the back of the envelope.
<DanC> ok, I'll write Misha and ask him for notes or a snapshot of the envelope or whatever
<timbl> we discussed some options with him
Vincent: I suggest that for the
moment we keep the discussions between the three of us and I
wasnt there for the discussion after the panel.
... Dan, I suggest you follow-up with him.
<timbl> "gave him" sounds as though we imposed constraints ... we suggested some solutions.
Vincent; and we can ask Henry next week to see if there is something else.
<scribe> ACTION: Dan to contact Misha to follow up on f2f discussion at AC meeting. [recorded in http://www.w3.org/2006/05/30-tagmem-minutes.html#action07]
Vincent: These two draft findings are not on our list.. Should we open new issues on our issues list for these drafts (two questions)
The work on these draft findings is already in the issues list, but behind these other issues.
Dan: T.V. you asked for an issue. Do you have an issue name?
T.V. I don't know if it needs a new issue or if it sits behind an issue name.
Dan: If you don't want a change, I'm happy with the current issues list.
T.V. Do you see the document that I'm proposing?
Dan: No, I don't see the document.
Vicent: Two issues; 1) title of your document and 2) title of the issue if we track it on the issues list.
<dorchard> Issue-State-52
T.V.: My preference would be to try and bucket this within a current issue.
versioning could be a place..
Noah: 41 is titled xml versioning
T.V. this goes beyond document versioning.
<DanC> GenericResources
<DanC> cf http://www.w3.org/DesignIssues/Generic
TV: what got me going on this is the mobil version vs desktop version.
Noah: I think that's different than XMLVersioning-41 then.
Vincent: well, we'll discuss it during our f2f so we can make a decision as to new vs existing issue at that time.
Dan: I suggested generic resources and tim seconded it.
timbl: as a new issue.
<noah> Hmm. Don't strongly object to GenericResources. Downside is that it's not quite self-descriptive. You sort of have to know what's intended before you understand why the term applies.
<noah> I do think it's a good issue. Wish I could think of more suggestive short name.
<DanC> yeah, GenericResources is not a great name, but it's the one that my brain files this under.
timbl: I think this is similar to site metadata where the TAG may end up doing some design.
<noah> I can live with it, and since I have nothing better to offer, I'll endorse it.
TV: I dont want to stick it in a bucket and then later find I'm constrained by that bucket.
<DanC> http://www.w3.org/DesignIssues/Generic
<DanC> http://www.w3.org/DesignIssues/Generic
<noah> Seeing that the term has been out there in Design Issues give's me a bit warmer feeling about the short name. I vote we adopt it and move ahead.
<timbl> A generic resource is a conceptual resurce which may stand for something which has different versions over time,different translations , and/or different content-type representations. How shoul done indicate the relationship between these?
<noah> Strong yes to picking this up as an issue. Weaker yes to adopting the short name GenericResoure
<DanC> issues face by and bp for publishers who have a need to produce a piece of content but publish multiple version varying by time, device, [others]
<DanC> ^TV's suggested 1-sentence summary of the issue, which I support.
<Norm> +1 from me too
Vincent: is anyone opposed to opening a new issue for this GenericResources topic?
<noah> Didn't have time to bring it up, but I'll leave these tracks in the minutes to suggest I'd be interested in thinking about fragid's and generic resources. Maybe that should be part of the story?
Vincent: so it seems the TAG agrees with opening a new topic.
RESOLUTION: open a new issue for GenericResources-53
Vincent: TV I'll need a few words to announce the issue.
TV: Ok, after the f2f, I just needed this as a placeholder.
Vincent: Yes, but I'd like to
announce it now.
... ok, we need to have the same discussion about the state
finding but we'll do that next week.
... Thank you everyone, this concludes our meeting.