SV_MEETING_TITLE -- 07 May 2009

<scribe> scribe: johnk

<timbl> duh ..

convene

noah: any regrets?

ht: might not be here next week

<timbl> Regrets for May 21

ht: definite regrets for next week

noah: Jonathan can scribe

Minutes Approval

noah: cannot approve minutes of 2nd
... propose to approve 23rd minutes

APPROVED minutes of 23rd April

Admin

noah: reminds he has sent a summary of matreial

RESOLUTION: approve minutes of 23rd April

nameSpaceState-48

noah: gives background regarding Norm's draft
... Norm prefers not to drop entirely

<jar> it's short!

noah: resolve this issue in email

timbl: don't want to drop this either

<ht> +1 to publishing as a REC

noah: in addition to not dropping, do we want to have people invest time in this issue?

lmm: does XML Core WG have an opinion on this issue?

<ht> I have scanned 2009/04/02-minutes.html, and am happy with them

noah: suggest we solicit feedback on this issue in email

<ht> [Larry, a minor point -- I find the timestamps very distracting, can you turn them off next time, please?]

lmm: suggest an action to contact XML Core WG

ht: agree would be a good idea to contact them

lmm: if XML Core wants us to work on this, then we should, if not, then we shouldn't

noah: suggest email discussion to be followed by a future agenda item
... will anyone take this action?

issue IRIEverywhere-27

noah: (gives background)
... significant concern was that 5 drafts were in roughly the same space
... ht took an action to review these drafts and find their relation

ht: action is pending review

<trackbot> ACTION-263 -- Henry S. Thompson to summarize LEIRIs and "4 specs" in mail to www-tag -- due 2009-04-28 -- PENDINGREVIEW

<trackbot> http://www.w3.org/2001/tag/group/track/actions/263

noah: tracking this now under IRIEverywhere-27
... shepherd?

lmm: I will be the shepherd

noah: Henry - would you like to lead this?

<DanC> (I did more formatting work this AM, fwiw. )

<noah> Dan, formatting on your draft with MSM?

<DanC> http://www.w3.org/html/wg/href/draft-ietf.xml and http://www.w3.org/html/wg/href/draft-ietf.html

ht: (talks about recent Connolly/Sperberg-McQueen draft)

<DanC> (Internet Draft ~= WD; Proposed Standard ~= Candidate Rec; Draft Standard ~= Proposed Rec; Standard ~= Rec)

ht: asked Martin Duerst to clarify where we stand with IRIbis
... so far he hasn't
... what to do next?

<ht> So where on that list does having an RFC number come in?

<Zakim> DanC, you wanted to look at Martin's response http://lists.w3.org/Archives/Public/www-tag/2009May/0001.html

<timbl> The .xml gives me "This XML file does not appear to have any style information associated with it. The document tree is shown below."

<timbl> by the way

<DanC> as designed

timbl: idea that if you find something hex encoded is actually UTF-8 is actually wrong

<noah> Dan: requirement is about non-Western search service, but I don't understand it very well. Tim do, you know about URIs from Baidu.com.

<noah> Tim: HTML meeting at TPAC. The machinery for HTMl URLs can generate things that look like encoded IRIs but are not. So, you cannot assume that anything hex encoded is UTF-8 is not true.

<timbl> This is because the HTML system has its own way of encoding params from HTML forms into URIs

<noah> Tim: HTML meeting at TPAC. The machinery for HTMl URLs can generate things that look like encoded IRIs but are not. So, the assumption that anything hex encoded is UTF-8 is not true.

<ht> DanC, draft-ietf.html looks better, but still two major problems: 1) it's not well-formed (try ,validate); 2) the scope of ed-notes is still unclear

DanC: Martin's reply is more coherent

<noah> Can we copy the quote just read into our minutes here?

<noah> Well, the problem is that when a server gets data (in a path component,

<noah> and even more in a query part), they need to know what encoding it is to

<noah> make sense of it and provide a reasonable answer. The reason why you are

<noah> calling this the "search engine" problem may be that this problem is

<noah> most prominent with search engines, because everybody agrees that people

<noah> want to search in their language, not limited to US-ASCII.

<noah> But it applies to any kind of query parts.

<noah> Some search engines have their own way to passing encoding information,

<noah> as an example, in

<noah> http://www.google.com/search?q=%E9%9D%92%E5%B1%B1&ie=utf-8&oe=utf-8,

<noah> "ie" indicates input encoding (i.e. what's sent to the server, and "oe"

<noah> indicates output encoding (what should be sent back).

from: http://lists.w3.org/Archives/Public/www-tag/2009May/0001.html

<timbl> The HTML form convention is that the text in the text input field is in the same chset as the page istelf, and when the parameters is encoded in a URI, the same encoding as te HTML page is used.

DanC: firefox implemented it per IRI spec

<DanC> (the best way to slow down is to make test cases. here's hoping I find time)

DanC: two paths in their code.

<DanC> Martin's "Currently..." para bears out my experience with flags in mozilla

noah: when you say implement the IRI spec - assume that this is independent of content-type used to encode form

Danc: href youre looking at is inside a doc

with some encoding

noah: it's not any old anchor, it's on a form

submit

timbl: you have to encode what someone types in, in the language in which they're typing
... local encoding is used

danc: then someone bookmarks the URL

timbl: if someone follows bookmark, browser assumes UTF-8 and gets garbage

danc: HTML5 says don't do that, use "Big5"

<timbl> "Big5"?

danc: baidu uses big5
... put in some chinese chars, go over wire percent-encoded

<jar> 香蕉

danc: one of the links on that page is then copied into some other document

<timbl> http://www.baidu.com/s?wd=%D3%DA%B0%D9%B6%C8+

danc: href=... (encoded chinese)

noah: hex-encoded?

danc: good question - think not
... that uri might get passed to a script

<timbl> http://www.baidu.com/

danc: even though script is in utf8, browser has to keep track of "big5" encoding

<Zakim> masinter`, you wanted to talk about IRI specs and normative behavior and to separate out: definition of protocol element(s) -- Web Address, LEIRI, IRI -- behavior of form

lmm: comment about distribution of guidelines across specs.
... some material might be misplaced
... moving the guideliens aroiund might make things clearer

Big5: http://en.wikipedia.org/wiki/Big5

lmm: URI document defines at least 3 protocol elements

<noah> Chair is starting to wonder what next steps are going to be after this discussion lurches to a local minimum.

<noah> Help?

lmm: gives some syntax, but there is a separate set of advice on how to ship around URIs

<DanC> (I count 2)

<DanC> ah.

lmm: some of these things refer to full URI which allows a fragment, some to one without a frag
... you can send a path without a fragment or a full URI without a frag
... IRI doc could restrict itself to defining protocol elements
... other specs. could discuss behaviour
... how to take a form and data entered into a form
... if method is GET turn form submit URL into URI/IRI
... advice is more behavioural than protocol-related

noah: let's step back here
... we took note of DanC/Michael's document
... we noticed there were several specs. in this space
... view this discussion as fact-finding on baidu space
... noted Larry's comments
... should the TAG do more now?

DanC: interested to go around the table?

noah: what, if anything, should the TAG do in this space in the next few weeks?

don't feel sufficiently informed, so abstain

raman: don't know what the TAG should do over and above what Dan is already doing
... suggest 'nothing'

ashok: abstain

ht: only body which is in position to do more in this area is us!
... not sure how to make something happen here
... but something needs to happen
... we should have a meta-discussion
... what should happen here, and what can the TAG do?

lmm: getting better clarity around URIs on the Web is one of the more important areas of Web arch
... worried about it myself, and would be delighted to have fellow worriers

noah: we can schedule future discussion but is there anything more concrete?

lmm: willing to take an action to work with Dan to get a list of tech issues

danc: need this audience to checkpoint my work
... seems some people are involved, and would like to take away reasons for others who abstained

noah: schedule discussion for next week, or wait till next draft?

danc: Larry's action seems to be useful to me

noah: wait for progress on action

jonathan: not sure I can contribute, but if Dan writes something clear I would be happy to review

noah: hearing interested concensus

timbl: priority is to describe current situation

<DanC> (ah... yes... if LMM's action morphed to "work with ht and DanC on (a) some orientation paragraphs, (b) some issues/test cases" that would be optimal, I think)

timbl: henry suggested "how the world could be better"
... and how to get there, if possible
... tag set the expectation that IRIs and URIS could be interchanged, and now we have situation where they are not
... should describe this

<jar> !

ht: on the specific question of what should happen to make things better. I meant that there is only one spec. going forward and everyone agrees

timbl: that is one good area to tackle

<DanC> (when did the TAG set the expectation they could be interchanged? Some of us repeatedly said they could not all along.)

timbl: maybe we can draw the line on where we expect to have IRIs?
... if you have some things encoded, you can't use it in certain places?
... or all docs. use UTF-8?
... don't have hopes of any of these things right now

<noah> jk: i'll be happy to review what Dan produces

noah: my answer will be factored into my proposal
... I think I want to key on Larry, Dan and others to frame the technical issues
... heard input on what those issues were from timbl
... Dan said he finds this useful
... propose assign an action to Larry,. Dan to do the analysis
... any better/other suggestions?

<scribe> ACTION: DanC to work with Larry, Henry to frame technical issues relating to the vairous overlapping specs. about URIs, IRIs and encoding on the wire [recorded in http://www.w3.org/2009/05/07-tagmem-minutes.html#action01]

<trackbot> Created ACTION-265 - Work with Larry, Henry to frame technical issues relating to the vairous overlapping specs. about URIs, IRIs and encoding on the wire [on Dan Connolly - due 2009-05-14].

<DanC> action-265 due in 2 weeks

<trackbot> ACTION-265 Work with Larry, Henry to frame technical issues relating to the various overlapping specs. about URIs, IRIs and encoding on the wire due date now in 2 weeks

<DanC> action-265?

<trackbot> ACTION-265 -- Dan Connolly to work with Larry, Henry to frame technical issues relating to the vairous overlapping specs. about URIs, IRIs and encoding on the wire -- due 2009-05-14 -- OPEN

<trackbot> http://www.w3.org/2001/tag/group/track/actions/265

<trackbot> ISSUE-60 -- Web Application State Management -- OPEN

<trackbot> http://www.w3.org/2001/tag/group/track/issues/60

webApplicationState-60

noah: we published a WG, so what should we do next?
... Ian reminded us about patent exclusion disclosures
... check with Ian/lawyers about patents as we are considered "invited experts"

<Zakim> DanC, you wanted to suggest aiming for Note

noah: understood group wants to move this draft to REC

raman: this is about coming up with best practices

<DanC> "disappear"?

raman: but w3c has nothing between 'note' and 'rec'

DanC: notes don't disappear

<timbl> Note sounds good to me

lmm: we might want to get some clarifications, but if you have nothing normative, then no "essential claim" possibilities

noah: question is still about whether we call this a rec

lmm: I defer to Dan on w3c process issues

do we need to make this decision now?

noah: some pressure to do patent disclosures if we go for 'rec'

timbl: what is a "TAG finding"?
... what's wrong with making this a finding?

noah: maybe nothing...
... we did discuss how to get more visibility, and 'rec' is one way to do that
... propose we take this to email
... poll
... would like to see more work in this area

I guess the question is "what level of interest is there in seeing this work pursued?"

noah:

yes

ht: yes, but have no cycles

danc: html media type needs to be updated
... challenge is to get it reviewed by relevant audience: jquery, dojo et al

timbl: work is valuable, and would like to wrap it up
... we tell story in WWW + findings
... make it a finding
... then, what should we do to assembled what we've produced into a new arch doc?

noah: next f2f might be a place to discuss assemblage of findings into arch doc

see value to this work, should keep going

ashok: see value to this as note or finding

lmm: would like a more formal external review, ie. outside of TAG
... worth being a rec, but needs broader review, AC approval and so on

noah: sounds like a suggestion to go to REC

lmm: yes
... important part of web arch

noah: hearing "yes, let's keep working on this"

raman: don't see the difference between doing this as a personal blog post and doing this as TAG finding

timbl: TAG findings have a role in Web community

noah: findings have a formal goal

raman: not seeing much momentum in this work
... (seeing this as perhaps a larger problem with recent findings)

noah: asking what is the next step, and if no-one is willing to help, then I can see how you would be frustrated?

raman: prepared to see what happens

noah: give this some thought - if you can figure out what next steps are, then lets discuss at f2f

lmm: let's send out a note saying we're going to review it, and would appreciate external comment

ashok: good idea

<scribe> ACTION: noah to send a note to www-tag pointing out that discussion is open on the WD for ISSUE-60 [recorded in http://www.w3.org/2009/05/07-tagmem-minutes.html#action02]

<trackbot> Created ACTION-266 - Send a note to www-tag pointing out that discussion is open on the WD for ISSUE-60 [on Noah Mendelsohn - due 2009-05-14].

lmm: summarize versioning work
... reviewed Dave's draft and wanted to reconcile work from there - wanted to see whether I was going in a "new" direction

noah: can you look at background reading in this agenda and modify it if necessary?
... propose to adjourn

(adjourned)

<timbl> Thank you, Noah

- DRAFT -

SV_MEETING_TITLE

07 May 2009

Attendees

Contents