See also: IRC log
No comments on agenda
Resolution: Minutes from Sep 4 approved http://www.w3.org/2008/09/04-tagmem-minutes
Next week call a risk. Regrets from Tim. Stuart may not be able to make it
HT: Use the time to read our documents
Cancel next week's meeting
<jar> +1 use the time to read
Next meeting f2f
Raman: If we are serious abt this, all TAG members should read the HTML spec
DanC: Please let's finish reading list and Agenda for f2f
<Zakim> ht, you wanted to acknowledge my EXI actions
HT: I will read these on the 'plane and make a recommendation on what we should do
DanC: Last, we said tell us how you are better than gzip
HT: That's where we are, the ball is bak in our court.
SKW: We will discuss this again at our FTF.
<DanC> (though Dec sounds wierd... I thought our request was since Dec)
HT: I'm working on a new document. Shd have it ready middle on next week
<DanC> close action-167
<trackbot> ACTION-167 S to start a thread on non-DNS authority resolution on www-tag closed
DanC: What's happening with XRIs?
SKW: Summarizes situation
We have not had a formal proposal saying would you be happy with ...
SKW: We had a discussion on how the discussion was going
<Zakim> DanC, you wanted to check whether skw meant it when he said "prefix", since DNS names go least-significant-first
<DanC> does either Booth or Bradley advocate an actual prefix?
<Zakim> ht, you wanted to say there's one thing we will need to chase no matter what
<ht> Abstract Identifier document: http://wiki.oasis-open.org/xri/AbstractIdentifierArchitecture
<jar> saying "http://xri.*/*" are XRIS is same as saying "http://*/ark:*" are ARKs ...
SKW: That's not the proposal (to <jar> above)
<ht> And I think there is _some_ room to argue that both of these are OK, if not ideal
Noah has incorporated feedback from Norm and SKW:
SKW: Norm and I would be supportive of publication
<Zakim> ht, you wanted to ask a question
ht: In a discussion with a student I realized ...
<ht> I believe the following: "FYN works iff every party to the story is a) publically accountable
<ht> and b) aware of the dependency of the FYN story on their part of it.
<ht> "
<DanC> I think you can follow-your-nose into policies and such that aren't world-readable
DanC: I would not say 'publically accounatable"
HT: The parties have to be publically accountable
SKW: The draft does not say this
HT: I would like to discuss this
SKW: Pl. send comment
DanC: I disagree for 3 reasons
<DanC> (I ran out after 2)
<DanC> (1) need not be world-readable
<DanC> (2) the URI for text/plain isn't actually critical path
<DanC> ... currently
<DanC> (though it's nice that the text/plain full URI is in an RFC)
HT: I will send mail on this
<Zakim> DanC, you wanted to think about whether RDFa is critical path: if we leave it aside, what's the audience/purpose? and to
DanC: How can we finish without RDFa
story?
... I'm not sure story holds up
SKW: can we document missing link and encourage them to put it in place.
<skw> http://www.w3.org/2001/tag/2008/09/f2fkc-agenda
SKW: Talks about the f2f agenda. Thanks Raman for his help
DanC: I would like to negotiate the reading list now
<DanC> I hear from skw: urnsregs, binaryxml, html*,
<DanC> digest of ?
SKW: Should read binary XML specs, HTML spec, collected digest of refernces from Raman's thread
<DanC> self-describing web draft
<DanC> passwords in the clear
Self-describing Web, Password in Clear, Versioning
<DanC> versioning revision from david
Need two readers for Binary XML, HT is one.
URNsAndRegistries-50 ... HT writing paper. Due Tuesday. Shd be read by f2f
<DanC> * tim's bit
HT: We should all have read Tim's paper
<skw> also had an explicit request from David for Jar's formal treatment...
<DanC> "the document"... one document on versioning?
<DanC> DO nominates JAR's formalism
DaveO: What is new is Jonathan's formalism. Recommend people read this by f2f
<DanC> DO: key chapter is ch5
DaveO: Please review Chapter 5. That is new and is key
<DanC> HT nominates SVG and HTML thread from public-html... a dozen messages
HT: Read SVG and HTML thread. Read 10 msgs and get a feeling of the context
<DanC> TVR 2nds... long thread... read for motivations
<DanC> (looks like TVR's agenda input subsumes HT's suggestion to read a thread)
TVR: Read HTML spec with a view thru the structuring lens I proposed
JR: Is there a document that tells why W3C got involved in html5
<noah> Are you discussing reading list?
<jar> http://wiki.oasis-open.org/xri/AbstractIdentifierArchitecture
<jar> ?
DanC: I can point to formal mataerial but that's not what you want
<DanC> on mime types... a section of the html spec
<DanC> pwinc fri
<noah> Friday's OK if short, I think.
<DanC> (thanks; I was just gonna ask for irc convirmation)
Noah: Are we all supposed to read whole HTML spec?
<DanC> nm nominates thread on meeting goals
Noah: Please read thread on Tag Soup
HT: Norm is not coming to Kansas City
<skw> I think that the thread Noah referred to is based at: http://lists.w3.org/Archives/Member/tag/2008Aug/0019.html
DanC: I will send mail before EOD after editing agenda page
Possible topic GenericResources-53
Content negotiation and Abstract Documents
Not on agenda currently. You can lobby me.
TVR: Steve said he was pulling in my TPAC proposal
SKW: Asks abt status of CURIE comments
<DanC> (anybody have a summary of the comment? the subject line was a generic "comments on X")
Noah: That's for responder to say
SKW: Summarizes comments
Editorial: QNames never intend as attribute values. Some discussion on this
<DanC> (pls promote that "main substantive comment" to the subject line)
SKW: Definition of XML Schema datatype
<ht> Please remember that we have already fed back on this point, see http://lists.w3.org/Archives/Public/www-html-editor/2008JanMar/0014.html
AM: Noah you had a comment on lack of clarity between CURIE and URI where there is ambiguity
Noah: I sent this as a personal comment. If no objection, I can add to my note
<jar> the whole point of safecurie was so that they can be put in uri contexts
<DanC> yes, now that I understand the comment, it seems to miss the point of safecuries
<noah> Well, it hijacks the use of [ in everyone's languages.
Raman: I'm uncomfortable with this. We need to allow new syntax in old contexts
jar: If there was no intention of extensing URI content there would be no SafeCURIEs
<jar> RDFa already would violate a prohibition on safecuries. It's too late to prohibit safecuries
HT: We should be careful abt distinguishing between CURIE's and SafeCURIES
<DanC> <ht> Please remember that we have already fed back on this point, see http://lists.w3.org/Archives/Public/www-html-editor/2008JanMar/0014.html
HT: We should not go back on that advice
TVR: The way Noah phrased it it sets a very high bar for new syntax
<jar> Two questions here! (1) CURIEs in URI contexts? (No.) (2) SafeCURIEs in URI contexts? (RDFa requires.)
<Zakim> noah, you wanted to say implying safecuries can be used in existing languages where URIs are expected hijacks the use of [ in those languages.
Noah: Explains his POV ... I should open my spec to other syntax
<jar> relative URIs can start with [, yes?
They should make clear that these things are not URis
DaveO: Supports Noah. CURIEs cannot be wedged into existing specifications
<jar> I repeat: There are two questions here! (1) CURIEs in URI contexts? (No.) (2) SafeCURIEs in URI contexts? (RDFa requires.)
<DanC> jar, does RDFa use <a href="[safecuri]">? I see deployment problems there.
<skw> http://www.w3.org/mid/48B810F4.60807@aptest.com
DaveO: Must specify how CURIEs and URI are disambiguated
<jar> no, but it allows safecuries in other uri contexts, I believe. Will check.
<DanC> ok. deployment considerations for a/@href are somewhat special
TVR: XSLT uses { } is attribute value templates. Example of use of a special character
<jar> ok, URIorSafeCURIE only occurs in attributes that are newly added by RDFa
<noah> I did propose text to Shane on 8/29:
<noah> <proposed>
<noah> CURIEs and safe-CURIEs map to IRIs, but neither a CURIE nor a safe-CURIE
<noah> <italic>is</italic> an IRI or URI. Accordingly, CURIEs and safe-CURIEs
<noah> MUST NOT be used as values for attributes that are specified to contain
<noah> only URIs, IRIs, URI-references, IRI-references, etc. Specifications for
<noah> particular attribute values or other content MAY be written to allow
<noah> either CURIEs or IRIs (or URIs, etc.). The specifications for such
<noah> languages MUST provide rules for disambiguition in situations where the
<noah> same string could be interpreted as either a CURIE or an IRI. One way to
<noah> do this is to require that all CURIEs be expressed as safe-CURIEs,
<noah> implying that all unbracketed strings are to be interpreted as IRIs.
<noah> </proposed>
TVR: I'm mostly OK with this.
<DanC> x:y
JAR: I'm bothered by saying "CURIES are not IRIs". There are strings that are both.
<DanC> noodling... "neither every CURIE nor every safe-CURIE <italic>is</italic> an IRI or URI"
Noah: I will put this in a note to the TAG list and people can comment
<noah> So, Stuart, what's the next step on the response.
SKW: Let's conclude on email.
<noah> SKW: Noah to redraft considering Stuart's proposal on intent of QNames and add 8/29 draft text on using CURIEs where URIs expected
SKW: DanC, any progress on 171
Dan: No.
<DanC> p.s. any hosting issues?
<DanC> hmm... decisions decisions...
<DanC> collect all preparation materials in one place in the agenda...
<DanC> or tuck them under the relevant items?
<DanC> I lean toward tucking, so far
<DanC> hmm... how to do a crawl-and-zip...?