Re: ISSUE-58: the simple solution to inlined membership

> The problem with your proposal was that a server that serves 
> consistent data and a client that does correct reasoning can end up 
> with a wrong result regarding whether members are inlined or not.

This can occur in general regardless of LDP's presence or absence.

If some server implementations choose to provide additional levels of 
guarantees about this, or change the interaction model by removing certain 
optimizations that surface inconsistent triples in a certain way, or 
support certain scenarios demand global consistency across all the content 
of a container, they are free to do so with LDP as it is today.

I'm very much in favor of *informing* them of the trade-offs so they can 
make *informed* decisions.
I'm very much against removing choices from implementers when we have 
clear and understandable issues that the choice helps solve.


> - You are confusing document creation ( LDPC create new GETable 
> resources) with talking about objects
> these documetns talk about. The examples in the sepc are all moving 
> into HTTP range-14 space, by confusing
> those. 

A bit of real-world "talking to devs" experience: many of them - all minus 
one or two, of dozens I have dealt with, do not care about this 
distinction and find it confusing when it is forced into view.  This is 
not however because they are bad people, [insert your own favorite 
'insult'/way to dismiss them]; it is because their *current scenarios* do 
not need the distinction, and they (rightfully so, in many minds) eschew 
anything not needed.  Agile thinking leads them there, in part.

I am of two minds on this:
(1) I happen to agree that over the longer term separation is clearly more 
precise.
(2) All my experience tells me that if we (try to) force something on them 
that they do not see as relevant to their scenarios, we'll just be 
inviting them to ignore us (playing the "crazy uncle" role).

As long as it is possible to refine the model over time, to introduce the 
separation later, I am thinking that the middle road is to be explicit 
that people do both, and the problems that emerge when they fail to 
separate things precisely.  Your examples, coupled with http-range-14, 
lead me to think this precision can be introduced after the fact ... 
perhaps with some client impact, but being explicit about that price to be 
paid is how we can convince/lead people without appearing to be religious 
zealots of the sort pictured in your Google+ chat from 2011.

I would prefer to admit everyone (show at least some examples both ways), 
offer to instruct willing learners (be explicit about the implications of 
the differences - I think you provided some very succinct examples 
already), and let history sort out the rest via adoption, rather than 
holding The One True Answer close to my heart and depriving the Bad 
Modelers as you call them from even having the chance to reason it through 
for themselves.  I prefer this because I see in the latter a route to 
obscurity.  Purity perhaps, but a purity that will touch far fewer 
adopters.

> Good so why not just PATCH an LDPR? 
> That would simplify the spec, and we could finish this first 
> version, and it would be very flexible.
...
> So create one LDPR that you can work with by PATCHing it.
...
...and others

These seem to largely net out to the same "do it my way" argument that 
would be consistent with my "holding The One True Answer close to my 
heart" approach.  Perhaps we should decide as a WG where on that spectrum 
we choose to reside.  I'm not arguing that "your way" is at all wrong 
either, Henry; I might/not agree with any particular example, that's not 
the point I'm interested in.

I think this comes down to a choice between inclusiveness and exclusivity 
in terms of how the working group wishes to approach its problems.  Where 
on that spectrum do we wish to be, and how much/to what degree are we 
willing to trade off points of purity against what non-experts in the 
space find consumable?  Can we live with the fact that people make 
modeling choices that we wince at, and try to convert them as equals 
rather than legislating ours as the only way?


Best Regards, John

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