Re: Action-126: Proposal to materialize ldp:contains

> With your proposal, LDP will depend normatively on this, so we'll have
> to hope that these dependencies will become stable soon enough for LDP
> to go to REC.

Speaking as a certified lead-lined tinfoil hat wearer, the easy solution 
is to make it At Risk and make the call at CR.  If we dump it at CR, then 
clients get all triples in 1.0, this probably lands on the ".next" list, 
and anyone who cares can implement the draft as an extension.  Fin.

> > from the client) would normally return them.  LDP could try Must'ing 
that,
> > at the risk of eliciting more comments along the lines of Mark Baker's
> > (and perhaps Erik W, and IETF generally)
> [snip: Alexandre's insertion]
> > that we're intruding on base
> > specs by over-specifying how servers form representations most 
appropriate
> > to the client according to WebArch.
> 
> Can you say why you think this is "over-specifying"?

I'm not saying that I think it is, I was anticipating others' likely 
responses based on past experience discussing their comments (and their 
reasoning that led to same) with them.  My perception is that they are 
strong advocates for a point of view that gives the server huge amounts of 
freedom in determining what the "right" response is for a given situation. 
 It's that position that leads to conclusions like "200 + a subset of the 
state with links to more of it is fine" (how to respond to a GET when the 
server decides to page the result).  While not everyone agreed with that 
specific conclusion, it's a point of view that I see coming through in 
many IETF specs.  "over-specifying" was my way of summarizing that 
position, is all.

> 1. Does this replace 5.9.1 altogether? Do we still expose non-member
> and non-containment resources?

If we choose to adopt this mechanism to ALSO cover the 
non-member-properties case, I think exposing them is server choice.  Any 
minimalists would probably then conclude "remove all mention of them 
[non-member-properties , non-containment resources] from the spec - it's 
complex enough already".  I would have sympathy for that position, 
personally.

> 2. The spec does not prevent inlining (nor encourage it) and it _can_
> be useful for a hashless-ContainerResource to inline the containment
> triples from the related containers. I would then expect those
> "normally" inlined containment triples not to be returned if the
> client prefers to omit them. If you agree, do you think we should have
> a remark that mentions inlining in this proposal?

I don't think the spec even _contains_ the _word_ inlining at this point, 
given that we took a decision some time ago to remove it as an At Risk 
feature based on LC1 feedback (IIRC *I* removed it, and normally I'd 
search before declaring 'done').  I have not looked back at it after that, 
I have enough trouble staying current with the LDP email traffic.  Given 
recent progress on alternatives like TriG that are immune to the 
provenance problems that Henry alerted us to, those would be the first 
thing I'd look at personally.


Best Regards, John

Voice US 845-435-9470  BluePages
Tivoli OSLC Lead - Show me the Scenario