See also: IRC log
<trackbot> Date: 03 February 2014
<scribe> scribe: Andrei Sambra
<scribe> scribenick: deiu
Arnaud: let's get started; I'm not sure we'll need 1h30
<betehess> looks ok to me
Arnaud: approval of minutes from
Jan 27th, everyone ok with it?
... no objections -> minutes approved
... next meeting is set for next week
... maybe we can reduce the call length to 1h, depending on
content
Arnaud: Action-123 is pending
review
... it is still open for people to review it
<bblfish> hi
Arnaud: any other actions that
people can claim victory on?
... what about Action-118?
<JohnArwe> action-118?
<trackbot> action-118 -- Eric Prud'hommeaux to Report to timbl: some pref for reverting to 303, 200+header still on the table, henry considering 200+location -- due 2013-12-23 -- OPEN
<trackbot> http://www.w3.org/2012/ldp/track/actions/118
<SteveS> I made some progress on ACTION-120, just terms and some informative stuff...maybe 45% done with it
ericP: Arnaud and I are trying to
figure it out. We have a variety of actions. If they get a new
2xx code, what do they say? Ok, or 209?
... we just need to figure how clients with behave
Arnaud: the way things are going, we are not going to have the 2xx in time so we will probably revert to 303
sandro: can we do 2xx later?
ericP: now the spec says "use 2xx" and somehow involve the IETF to standardize it
<stevebattle14> zakim aaaa is me
sandro: it may take some implementations before IETF can move on it
ericP: we can exploit the W3C's
influence (?)
... we can just leave it there for now
bblfish: there was a discussion going on in the W3C arch group about 2xx
ericP: do you mean the TAG list?
bblfish: yes
ericP: the person who is taking this to IETF has reviewed all of that and convinced himself of a particular course of action, so we're good there
issue-93?
<trackbot> issue-93 -- Accept and Auth -- raised
<trackbot> http://www.w3.org/2012/ldp/track/issues/93
Arnaud: this is the last open
issue we have
... it has to do with the spec that doesn't mention
authentication and authorization
... the spec requires the server to send a list of operations
that the server supports
... the question is: should the server do that based on the
user's credentials and authorization level?
<bblfish> https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#ldpr-HTTP_OPTIONS
<bblfish> https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#ldpr-HTTP_GET
Arnaud: if you were to take into account that credentials is an expensive operation to do, this might be wasted time
<bblfish> Arnaud: it's section 5.3.2
Arnaud: we have thought about
removing the section from the GET, or just "soften" it to a
SHOULD
... this was added in response to timbl's comments
... I am afraid that softening/removing it might change timbl's
position
... it could be added instead to a "best practices"
document
bblfish: I suppose the question
remained a bit to the expense of calculating the level of
access
... there's two types of options: Read (always the same for
nearly any user when doing a GET)
... the argument was that it is expensive to calculate, give
that it might not be useful for the client
Arnaud: I am a bit reluctant to
adding authentication in the spec (we're not talking about it
anywhere)
... isn't there another place where we could mention it? It
might be better to avoid it and just mention that there are
external factors such as authn
SteveS: for some apps, the cost
of computing ACL is based on other logic...so it might be just
an application problem
... there are lots of different cases that lead to complex
rules
... it might be good to just put this in the best practices
document
<Arnaud> PROPOSED: Close ISSUE-93 doing nothing to the spec and adding appropriate language to the best practice & guidelines doc.
Arnaud: I haven't heard anything that makes me think we should change the proposal
bblfish: wouldn't SHOULD be better?
Arnaud: my main concern is that we made it a MUST to answer timbl's comments
<JohnArwe> +1
Arnaud: I'm just trying to address timbl's concerns
<ericP> +1
<SteveS> +1 think it is good to keep a must and provide best practices/guidance
+1
<svillata> +1
<betehess> +1
<pchampin> +0
<sandro> +1
<nmihindu> +1
<Arnaud> RESOLVED: Close ISSUE-93 doing nothing to the spec and adding appropriate language to the best practice & guidelines doc.
Arnaud: we have now officially
closed all the issues! congrats!
... let's move on to the spec's status
UNKNOWN_SPEAKER: I just wanted to
make sure that we stay on track as much as possible
... if you saw the list of actions, the editors have a lot of
work to do
... there is a lot of work ahead for the editors, so how do
they feel about the schedule?
SteveS: we have 9 editor actions
open
... 2 or 3 have a big impact, so maybe by next Monday we can
have some of them completed
... there is still the "preferred header" action that needs
some more discussion
JohnArwe, I'm agnostic on the syntax
Arnaud: we made a bunch of decisions to use the Preferred header, but TallTed asked "why not use URLs instead of keywords?"
<JohnArwe> ted's email is at http://www.w3.org/mid/24D52177-A2E6-46C4-B304-D7263FA5B82B%2540openlinksw.com
Arnaud: there shouldn't be much
argument, but I don't think this is a deeply technical
issue
... let's finish with the spec status first
... we'll go back to the issue after that
... the goal is to have a spec that is ready to publish and
that we can give to the group for review
... how does everyone feel about the schedule? is that
doable?
<SteveS> I can make it work
Arnaud: any comments on how much time people need to review the spec?
<betehess> 1 week to review should be fine
<betehess> but we may have some feedback to discuss about
Ashok: one week is ok, but then again maybe two weeks
Arnaud: I don't know if we need
to reach out that far, but we still have a 3 week period when
everyone can take a look and comment
... but I'm more interested in what the group members have to
say about it
... not much reaction...
<pchampin> not sure, but 1 week should be ok
<svillata> 1 week is ok
<ericP> we want to optimally leverage the pain of the editors
Arnaud: if we can do it in one
week, that would be great. Otherwise, we could maybe have 10
days.
... we can figure it out next week
... that still means that we would be done by March 3rd
... looking at it I see that it's pushing things a bit
further
if the last call ends on March 24th, then we cannot meet before that
scribe: what this tells me is that the f2f should be one week after March 24th
<SteveS> Conflict for me
<bblfish> what is the aim of the f2f?
scribe: is there any conflict for
that period?
... for the 1st week of April
... we first need to decide on the date before picking the
venue
<pchampin> that's just before WWW2014, isn't it?
<ericP> would decisions made on 1 April be binding?
Arnaud: I would like to sort out the comments that we might receive during the week of 24th
<svillata> WWW2014 - April 7-11
SteveS: I have a meeting in that period and there's also the WWW2014 conf.
<nmihindu> pchampin, WWW2014 -> April 7 - 11
<ericP> co-lo with WWW?
<ericP> oh, i think it's in asia, iirc
bblfish: what is the aim of the meeting?
Arnaud: to deal with any comments/issues we get out of the LC
<bblfish> www2014 is in Korea http://www2014.kr/
Arnaud: we don't know how many comments we get, so for planning purposes we should schedule ahead of time
bblfish: you need at least a month for people to review and send comments/issues
Arnaud: maybe not a month but 3 weeks
<SteveS> I'm in Seattle April 1-3 for http://www.alm-forum.com/
Arnaud: we should meet after that
for the f2f so we can address those issues then
... it seems we have nothing before the week of April 14th
<Ashok> Who is going to WWW2014?
Arnaud: my concern is that if it takes that long to address all the comments, it's going to further shift the schedule
<SteveS> not going to WWW2014
<Ashok> me neither
Arnaud: there is also the possibility to exit CL right away, but anyway, there isn't much choice
<ericP> i'm stuck at home 16-17 April
Arnaud: the meeting can last for 2 days if we have no major issues; is it ok for April 15th to 17th?
<ericP> rbing it
<ericP> bring it
<SteveS> Week of April 14th could work for me
Arnaud: we can look at it again
next week
... if we have proposals for locations...
Ashok: I'm thinking we can go
with 2 days if we don't have too many comments, or extend it
otherwise
... bblfish offered to host it in Paris
<ericP> paris would be just about doable for me
bblfish: Oracle also has offices in Paris :)
<ericP> at least a few hours/day
<JohnArwe> @betehess: in either Prefer proposal, we're defining something... either parameters or [forgets what other word is]. I think in the currently resolved syntax (mine), I only defined parameter names ... I don't know that we'd have the freedom to say those are interpreted as URIs; then again I don't recall anything in the RFC prohibiting doing so. If Ted's alternative involves parameter Values, we'd almost certainly
<JohnArwe> be able to say we have the authority to say how the values are interpreted.
Arnaud: let's go back to the issue about the Preferred header
<bblfish> I would like to help organise a meeting in Paris
betehess: I have two
questions
... first is about the syntax; I'm not sure what you guys mean
when you speak about syntax
Arnaud: it's just a way to express it in the header (how you use it)
JohnArwe: TallTed was wondering if we could have URIs instead of keywords
<JohnArwe> http://tools.ietf.org/html/draft-snell-http-prefer-18#section-2
JohnArwe: I'm not sure they can be interpreted as URIs, nor if the RFC mentions it
<betehess> my take is that we shouldn't try to make it a URI just like we did for rel=type
JohnArwe: the RFC offers different values for the production name
betehess: I didn't understand
TallTed's use case
... we only have a few places where we're not doing it already
(i.e. rel=type header)
... there's no URI there but we can still do a lot with it
<JohnArwe> In his email: All of these "ldp-*" strings could (and probably should) be
<JohnArwe> replaced with URIs which return their meanings.
Arnaud: for humans it is nice to
have URIs, as it can be clicked to get more info about it
... TallTed is not here to defend it, and no one is trying to
defend his proposal
... it shouldn't affect the spec that much if we just leave it
at it for now
<betehess> @JohnArwe, this comes at the cost of longer strings
Arnaud: we'll see if TallTed
considers it seriously and if he wants to defend it
... is everyone OK with it?
<JohnArwe> the biggest effect I know of on the spec would be, if we go with Ted's, we remove the "omit" preference registration and just describe the parameters we're adding to return=minimal (which already is registered by the RFC)
Arnaud: there's a possibility to
compress the timeline by skipping CR
... CR was introduced to encourage people to implement the
spec
... it's a way to assure devs that the spec is stable and that
it can be implemented
... we have to define an exit criteria
... there's a question of the test suite and harness
... it may not be possible that the test harness can test all
implementations
... I expect the exit criteria for the CR to be rather in the
form of claims; people saying that they have implemented the
spec
... we need to define a minimum number of implementations
... even with all of that, how long will people need to
implement the spec, where "implement" doesn't need to reach
production levels
... seeing that the spec is changing, it may take time for
people to update their implementations/prototypes
... who can we depend on for implementations?
<Zakim> sandro, you wanted to ask about client libraries
sandro: I've been thinking about
this a lot lately. One thing that I'd like to have is a client
library that hides all the complexity of the different things
the server can do
... I want to be able to traverse a container for example
<ericP> sandro, GET /Container -> gives you a language-native iterator?
sandro: the client should
understand the different kinds of container types and
membership predicates
... paging too
<SteveS> I fully intend to have simple JAX-RS+Jena server reference impl out through http://eclipse.org/lyo project, already have a start
sandro: I'd also like to see a test suite
<SteveS> sooner than later
<JohnArwe> @sandro: "traversing" => membership triples, containment triples, either? or also non-member props?
Arnaud: test suite is important
<nmihindu> We have an implementation (ALM iStack) which implements first LCWD (without some features such as paging) but then we stopped updating it until the spec becomes stable again with the latest changes. We will update it when we go for the second LCWD.
Arnaud: also domain specific
tests should be nice to have
... there's a link to a Wiki page that lists LDP
implementations
... people added references there, so these are the first
things that we can look at for possible claim compliance
<JohnArwe> @ericp: all oslc specs are world-readable
Arnaud: can the people who posted there step forward and commit to implementing the spec?
<sandro> JohnArwe, either, I think. To the client, it's just a container with resources in it, to a first approximation. The client library should provide that view, given all the different ways the server might do it.
<ericP> @JohnArwe, i mean the actual endpoints
Arnaud: if we have 3 implementations by the end of the LC, we could possibly skip CR
<Zakim> ericP, you wanted to ask if any OSLC stuff is world-visible
<JohnArwe> @ericp: most of the reference implementations for oslc are in Eclipse Lyo, same place Steve is doing the LDP one
<SteveS> OSLC is "world visible" http://www.oasis-oslc.org/ for OASIS stuff and http://oslc.co for main site
ericP: I was wondering if any of those implems happen to be world visible? Do they require authn?
SteveS: OSLC is waiting for the spec to be stable
sandro: can you sync that with the REC?
SteveS: we're pushing it and we
have a lot of motivation to have it implemented
... we have internal implementations working
<JohnArwe> @sandro: I can imagine that your abstraction layer library would also turn "prefer" into "must" if necessary by filtering out extras. e.g. if client prefers membership only, and the server ignores preference, your lib could filter those out.
<JohnArwe> ...those = containment, non-member props
SteveS: we're working on it but it's difficult to provide a definite date
<nmihindu> Apache Marmotta is also waiting for the spec to become stable
Arnaud: nmihindu what about you guys? I know you've been working on it
https://rww.io is going to support it too
Arnaud: what about you, betehess? Can you make a claim?
betehess: yes, definitely
Arnaud: it looks like we might have enough implementations
<betehess> good question from Sandro, as I already know that I won't implement _everything_
sandro: we need every feature to
implemented...
... is everyone going to implement all features?
<JohnArwe> I think our intent in Lyo is to implement all features
Arnaud: we might not have 3 implementations that support all features, but we can have all features spread between the 3 implementations
<nmihindu> sandro, it might be nice to add a another row to the implementations wiki to say which features that they plan to implement
Arnaud: we should avoid getting
stuck in CR
... there are specs that have been stuck in CR for a long time,
so let's try to avoid it
sandro: that has happened before, but they didn't have a product to showcase
<JohnArwe> can we use the LC2 review period to get the next level of detail from implementers? what they Intend to implement, even if that's not in-product?
sandro: it's nice to have a
validation of the spec
... if people outside IBM won't implement it, then it isn't a
good sign
Arnaud: ok, let's move on
... there are deliverables listed in the quick action
list
... this is a way to remind people that we'll need to work on
the deliverables
... since the charter expires in June, and we've pretty much
closed all issues, we should try to focus on deliverables and
finish them by the end of May
... any activity reports on them so far?
stevebattle14: quick update on
the use case and req: I've put the spec status as WD
... we should use WG-notes as a solution to not have it be
listed as REC
<betehess> the problem was in the text in the spec
Arnaud: is the use cases and req document published as notes?
sandro: yes, that's a WG notes document
<nmihindu> LDP Primer update - We didn't include the latest changes that we discussed in the primer. When the spec becomes stable with all the resolutions incorporated, so probably next week, we will start working on the primer and modify the examples accordingly. We might be need a bit of restructuring to fit in basic containers, direct containers, and indirect containers better.
Arnaud: I saw an email mentioning that there was a problem with the status of the document
<SteveS> I know the test suite is out-of-sync with the section renumbering of the latest editor's draft
Arnaud: we can figure out the right way to publish
sandro: non-normative should be used instead of informative
<Arnaud> :)
<nmihindu> SteveS, raul was waiting for the spec and numbering to be stable to update the test suite
betehess: now the editors need to use the right headers in the document
<ericP> can we use "informative" and "non-informative"?
<stevebattle14> will do
<ericP> where "non-informative" is the opaque stuff that no one ever reads?
betehess: we can just change the metadata in the database and make sure it's ok in the next published version
<SteveS> nmihindu, understand...just sharing that with the WG
<betehess> ericP, ask ian
Arnaud: we can sort that out, it's ok
<JohnArwe> @sandro: for those Outside spec writing circles, "informative" (as a positive, avoiding the initial negative non-) has been more readily understood amongst my devs.
Arnaud: I would like to close the meeting at this point
<stevebattle14> We will set specStatus='WG-NOTE'
Arnaud: anything else?
ericP: is there a template RFC we
can use for 2xx?
... just in terms of the structure
... "here is a short RFC that defines the new status codes in
terms of two existing status codes"
... it should have the references at least
JohnArwe: we can instantiate the
template for our use
... I'm looking at it right now, if you're still around in IRC
after the meeting
SteveS: I wasn't sure if something that you need is commented out in the spec, since we had 209 commented out there
ericP: my preference is to do
this in plain text, RFC-like format
... we might actually end up uncommenting 209 from the spec, if
we promise that we'll write an RFC for it
JohnArwe: you can put it in
informational RFC
... it's non-normative
<pchampin> @ericP how about http://tools.ietf.org/html/rfc6585
sandro: why not use a W3C note
instead?
... never mind, the 2xx should be an RFC
<JohnArwe> @ericp: http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-25#section-8.2.3
ericP: we will do less work if we start with an RFC (if it progresses reasonably)
<JohnArwe> which will make your LAO, then cry a bit
Arnaud: we can now close the meeting
<betehess> bye!
<stevebattle14> bye
<JohnArwe> @ericp: you might use the Accept-Post draft shell as a wrapper, since that's what you're really after. erikw emails on LDP list have ptr to it.
<bblfish> betehess: are you implementing the code with Spray?
<ericP> JohnArwe, roger -- tx
<Arnaud> trackbot, end meeting
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/ericP/Arnaud/ Succeeded: s/Arnauld/Arnaud/ Succeeded: s/ericP,/ericP:/ Succeeded: s/"keywords"/strings/ Succeeded: s/SteveS,/SteveS:/ Succeeded: s/non-formative/informative/ Found Scribe: Andrei Sambra Found ScribeNick: deiu Default Present: ericP, Arnaud, pchampin, SteveS, Ashok, Sandro, Andrei, Alexandre, JohnArwe, nmihindu, bblfish, svillata, +44.754.550.aaaa, stevebattle14 Present: ericP Arnaud pchampin SteveS Ashok Sandro Andrei Alexandre JohnArwe nmihindu bblfish svillata +44.754.550.aaaa stevebattle14 WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 03 Feb 2014 Guessing minutes URL: http://www.w3.org/2014/02/03-ldp-minutes.html People with action items:[End of scribe.perl diagnostic output]