SWBPD VM TF -- 10 Jan 2006

<RalphS> PROPOSE: to move this meeting to 1500 UTC

fine by me (dialing in now...)

<RalphS> RESOLVED: to meet at 1500 UTC every week, starting next week later in the meeting this was changed to start on the 24th.

whether and how to cite design rationale

<RalphS> Ralph: I hoped for a mechanism that would not obligate us to exhaustively cite rationale

<RalphS> ... but that would let us cite relevant mail messages as we uncover them

<RalphS> Alistair: I'm happy with that

<RalphS> Tom: I generally like short documents with lengthy appendices

Tom: i want a sense of ... do we have same picture of target document, for end ... of April

Ralph: I think we should still have as a milestone to publish a doc this month, but recognise that we will be asking for a 3month extension of span of wg
... can anticipate an opportunity to update the doc

Tom: what would then be the sequence of events, process-wise?
... we have now the comments from the reviewers, ... one strongly suggests a change in structure of the doc, ... some are Qs of substance, but also big editorial Q about shape of the document
... pushing things off into appendix

Ralph: i propose we take those comments 1 at a time, see what to do about them, and think about implications for workload/timescale

Alistair: the 2 reviews we have, dbooths and andreas h's ...?

Tom: yes

<Zakim> aliman, you wanted to ask how the cookbook will relate to swbp comment on httpRange-14 and to ask: only hash or slash?

Alistair: I'm good for going thru david's review. Couple points to raise - 1st, exactly how the cookbook here relates to what the bp wg is drafting for http-range-14
... how scopes relate to each other
...also: given mechanisms we're using, ... redirects... why is it has vs slash, instead of hash-vs-anything else
... ie we can use any char, or no char, there

Ralph: re http-range-14, wg had some idea it might write something like a mail message or a tag-like 'finding', to try explain impact of http-range-14
... discussions with david booth, david wood, ...

i had goal w/ d wood, similar to this TF's approach

dbooth's goals are different, i feel

some independent draftings by both

some discussion in last WG telecon

scribe: probably not enough time to start a new doc
... things to say might be incorporated into cookbook instead?

david booth agreed to go to try draft a short section, for us to take a look at

Ralph: goes into design rational issues... we should leave designy stuff in our past, only deal with practicalities
... i added some prose re 'why you might want to think about this choice'
... not address tail end of what we all know has been a long debate

<Zakim> danbri, you wanted to comment re hash/slash char and to endorse this idea

i can't hear anything, suddenly

<RalphS> DanBri: from a user perspective, the W3C document that people will look at needs only to cover the practical aspects of the resolution of httpRange-14

<RalphS> ... not the historial argument

<RalphS> ... re: '/' or some other character; there's a class of characters that aren't permitted in xml names

Tom: I have a conflict next week 1500 UTC

<Zakim> TomB, you wanted to say I cannot make 1500 next week (17 Jan)

<Zakim> aliman, you wanted to comment on expanding scope of cookbook

Alistair: Ralph, if I understand right... you suggest expanding scope of cookbook, for other bits and pieces
... which pieces - yet to be decided
... in principle, am ok with that, especially if it lets things be published that would otherwise be left in email
... also to say generally that I really like Ralph's direction with document, especially the "we don't talk about hash/slash history" persepctive
... we talk to people as fresh visitors to the scene, ...

RalphS: you captured my intention precisely
... I took a little risk by suggesting this yesterday in the telecon
... I don't exactly know dbooth's goals, ... but some of what he's written could plausibly be recast as introductory material on how to choose reasonable namespace names
... I ack that there is some uncertainty and risk there

Alistair: i can live with the doc talking to not-exactly-1-audience

RalphS: I specficially asked... if dbooth is interested in this happening, that he propose the short section
... ball is in his court
... we can respond when we see the materials

danbri: is he thinking of joining the tf?

Ralph: he didn't suggest this
...
... I don't think the WG needs to provide a history of the whole issue
... connets with the design rationale Q
... I am inclined to give some people a little bit of assistance in understanding the 'why' re our design choices
... but I think there is a lot of benefit to -as al says- just moving on
... that's the past; here's what people should be doing in the future

DanBri: absolutely

RalphS: on other Q, of why we're so peculiar about /, vs other chars
... i think it is because / holds an identified role in URI space... notion of hierarchies in URI spec
... hierarchies in collections

[(at least in some URI schemes)]

scribe: not sure it pays to generalise notion of a separator char to other thigns
... people who want to do that can prolly figure it out from the cookbook
... but i don't think we need to generalise it for them
... no history/tradition in rdf corresponding to this practice

Alistair: if someone comes to this for 1st time
... i'm happy with ralph's answer

Ralph: we suggest there should be some separator character

TomB: ...and that historically, 2 separator chars have been used
... if people want to push boundaries, they won't be stopped by the cookbook
... but let's not open it up more than necessary

Alistair: am happy with that

DanBri: likewise

<RalphS> Ralph: agree, let's not try to generalize

<TomB> Ralph: slash has special significance in URIs as separator

<Zakim> TomB, you wanted to suggest we not offer more choices than necessary...

<RalphS> DanBri: I've been looking into namespaces that use non-Western scripts

<RalphS> ... e.g. Kanji

<RalphS> ... need to use IRIs for this

<RalphS> ... in right-to-left scripts there might be a case for having a right-to-left separator character

<RalphS> Ralph: do we have enough expertise here to do this now or should we leave it to later?

TomB: instinct is to stick to small number of cases that have historically come up

<RalphS> Tom: I have contacts but prefer at this time to stick with a small number of cases that we know and understand well

DanBri: am fine with using / and # (personally, I'll dig around the r2l case, see what people have done)

<Zakim> danbri, you wanted to offer an i18n example

Ralph: shall we go thru dbooth's comments here?

TomB: processwise... do we go thru each raised point on the BP list...
... make a decision on each, then when happy with a note candidate within TF, ask the WG?

(did i get that right? --danbri)

Ralph: at high level that's the task
... we treat the wg review the way the wg would treat an outside review
... ie consider comments/suggestions
... decide what to do with each
... implement or not such change; tell commentor what we've done

(I like that model --danbri)

TomB: you're suggesting we can do this by end of jan?

Ralph: yes, can/should by end jan
... which means satisfying david and andreas
...

TomB: ...number of decisions that need to be made, and editorial work, ... what's the model? Alistair making all the changes?
... in which case, he gets a big say re do-ability!
... seems like a pretty aggressive schedule

Ralph: what's clear is that we need to respond to each of their comments; but not necc accept each change.
... we can decide, and i'm suggesting... that some of our decision criteria be ... way we're aiming at our audience
... so some criteria we have already. But i also suggest that timing is a reasonable component.
... we can say we won't restructure this version, given time/resources available.
... we don't need to take their proposals as must-dos

TomB: timecheck - 12 mins left of call
... walkthru main points (see agenda), and hear back from alistair

(scribe help -- urls?)

Tom: we're not going to do more on hash/slash

Ralph: my proposal is that my new text in the doc (that was post- his review) addresses dbooth's point on hash/slash

DBooth's review http://lists.w3.org/Archives/Public/public-swbp-wg/2005Dec/0124.html

<RalphS> Ralph: PROPOSE that my new text addressed "trade-offs between hash and slash"

Tom: i didn't try to make a fully comprehensive summary of comments

<RalphS> ACTION: Ralph reply to DBooth/G1 with a summary of the new text [recorded in http://www.w3.org/2006/01/10-vmtf-minutes.html#action01]

Alistair: your summaries look good to me

Tom: what's the stance ... important to me, since dcmi use purl.org ... what do we do re purl.org?

DBooth/G2; 302 on purl.org

Tom: do we put it in, ... with health warnings? move to appendix?
... ( dcmi ?) will have to live with, or change, purl situation

<Zakim> danbri, you wanted to speak in favour of mentioning purl.org, in appendix

<RalphS> DanBri: mentioning purl.org in an appendix makes sense but in an agnostic way

Ralph: we got into the discussion of purl.org, because an important ontology that we care about uses it

(note that RSS 1.0 also uses it)

scribe: we might consider saying something about a hope that purl.org will revise their impl to do something else
... i don't feel comfortable ignoring it entirely, 'cos dc exists

Alistair: i'd be happy for the purl recipes to be included, appendixed, but they ought to be treated

<Zakim> aliman, you wanted to comment on purls

TomB: i tihnk they should be treated

<Zakim> TomB, you wanted to wonder what document DCMI (with others) to approach purl.org maintainers

TomB: wondering from dcmi perspective, ... i'd like to make a case to purl.org maintainers, ... wondering what kind of packet of info to make the case
... any positive reasons why 302 might actually be preferable?

Ralph: i suspect that 302 is an artifact
... can someone take an action to summarise G2 issue response plan?

Tom: that we'll put it into the appendix, won't remove it...

Ralph: decide how we'll treat Purl.org - that we shouldn't remove it entirely, but likely an appendix. 1 action is to implement that decision, the other is to report to dbooth.

<RalphS> ACTION: Tom report TF decision on G2/purl.org [recorded in http://www.w3.org/2006/01/10-vmtf-minutes.html#action02]

I was drafting this: ACTION: TomB summarise decision on purl.org cookbook treatment to the list and dbooth

(which is same)

alistair: if appendixing will make people happy, then let's do it

tomb: big change?

<RalphS> action 2=TomB summarise decision on purl.org cookbook treatment to the list and dbooth

Alistair: just seems like putting things in different headings. ...

Ralph: I'm a bit less inclined re moving it to appendix

Tom: inclined to agree w/ ralph
... don't need to decide here in the abstract. As editing happens, will be clearer.
... comfortable w/ alistair handling this

alistair: am happy with idea of passing on lead editor role, if appropriate
... not clear what our role, ...role of other tf members, should be, re editing the doc

<- that was tom not al

<Zakim> aliman, you wanted to comment on approaching purl.org re changing response code

Tom: beyond the brainstorming, wiki stage. But there are wordsmithable bits. How would you like to see work on this evolve, Alistair?

Alistair: I liked what Ralph did...
... reframing, in light of audience, ...
... ok with someone taking over at this stage; my main contrib was the tech detail

Ralph: not sure your pref,.. mine would be that you maintain the editorship of the doc, and that i had just worked on it for a bit
... that i pass it back to you, and we all offer you whatever help you need

TomB: should i feel free to help wordsmith?

Ralph: would you rather edit html in-place?

TomB: I can be picky on little things, which don't always deserve putting into a mail message

Alistair: Tom do you want to take over editing for a week?

Tom: can't right now

Alistair: best to do via email for now then

Tom: OK

[timecheck?]

[next meeting?]

Alistair: what I'm hearing from tom/ralph... maybe don't put purl into appendix
... but i should draft a parag "this is the important thing about purls that you need to know"
... the doc (per guus' comment) does have an awful lot of recipies
... wonder how to simplify choices in main body

ralph: same time 1400 next week

<RalphS> next meeting: 1400 UTC 17 Jan

<RalphS> then 1500 UTC after that

resolved: meet same time next week, after that, change to 1500 UTC

- DRAFT -

SWBPD VM TF

10 Jan 2006

Attendees

Contents

whether and how to cite design rationale

DBooth's review http://lists.w3.org/Archives/Public/public-swbp-wg/2005Dec/0124.html

DBooth/G2; 302 on purl.org

Summary of Action Items

Scribe.perl diagnostic output