Linked Data Platform (LDP) Working Group Teleconference -- 03 Feb 2014

<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

pending actions

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

<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

Spec 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

f2f meeting

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?

implementations

<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

- DRAFT -

Linked Data Platform (LDP) Working Group Teleconference

03 Feb 2014

Attendees

Contents

pending actions

Spec status

f2f meeting

implementations

Summary of Action Items

Scribe.perl diagnostic output