Re: Issue-71: the first bug tracking example

> R1.- IF no membership predicate from server THEN SHOULD use rdfs:member
> R2.- IF membership predicate not rdfs:member THEN MUST use 
> ldp:membershipPredicate or ldp:membershipPredicateInverse
> 
> In a more simplified way:
> R1'.- IF not A THEN SHOULD B
> R2'.- IF not B THEN MUST C
> 
> This has some problems:
> a) Even if in the mailing list people has been mentioned in several 
> times that the specification is totally understandable and without 
> ambiguity, for me statements such as these are quite difficult to 
interpret.

It's not just you.  The language is tortured.  Sometimes it's hard to 
avoid, but I think in this case it is avoidable with some editorial 
attention [points to self, scribbles down to-do].

> b) In the case of R1', we are not really forcing an LDP server to behave 

> in any way.

That's true of any imperative other than MUST/MUST NOT, so not scary on 
its own.
It's always a balancing act; every MUST/MUST NOT excludes 
something/someone.  That is their intent.  OTOH, every point of 
variability introduces complexity of at least one kind, and often several 
kinds.

> c) It is difficult (or even more than difficult) to define a test that 
> is able to check these rules. And, without test, it is not possible to 
> show that at least two implementations successfully satisfy our 
> requirements.

Not all requirements are testable.  That does not stop us from making 
them.  Eric P pointed this out explicitly during F2F2; I don't know if 
that was the first or last time, but I at least remember that one.  All 
other things being equal, of course, testable requirements are preferable. 
 The trick is agreeing with the antecedent.

> In this case, what we are doing is creating two profiles of servers 
> (again, not invented by me, W3C terminology [2]): those with their own 
> membership predicate and those without it.
> 
> This is what we are right now doing in the specification, and it is 
> something that I think we must not do in this working group.

Having read the cited text's definition of profile, it's a stretch to say 
that's what we have here.  "Discretionary item" is a better fit IMO.  And 
BTW [2] is a Note not a Rec.

So is it 'profile' in particular you are against, or this specific point 
of variability?

> Let's forget about profiles and just write the intuition that everyone 
> has in their minds:
> 
> R4'.- MUST B xor C
> 
> Simpler, understandable and testable.

I agree it's simpler in the abstract.  Less clear how well XOR renders in 
prose, but let's assume it's no worse.
You've lost the current recommendation (SHOULD) to use rdfs:member, or 
your re-write is incomplete when it omits R1'.
You've said that my server cannot both use rdfs:member and also assert the 
same via ldp:membershipPredicate ... which is not a crisis, but a subtle 
change.

> The drawback here is that we are making LDP clients quite difficult to 
> implement. Note that these are the requirements only for membership 
> predicates; just taking into account also those for membership subject 
> will add another D (use itself as subject) and E (use 
> ldp:membershipSubject). For the most simple interaction with a container 

> the client will have to analyse 4 scenarios:
> Subject Predicate
> D       B
> E       B
> D       C
> E       C

That's interesting; it doesn't seem nearly as complex to me.  I think if 
it as:
ms = ( c, ldp:membershipSubject   ,?   exists ) ? ( c, 
ldp:membershipSubject   , ms ) : (c);
mp = ( c, ldp:membershipPredicate ,?   exists ) ? ( c, 
ldp:membershipPredicate , mp ) : (rdfs:member);
membershipTriples = ( ms, mp, ?)

> Let's drop profiles and ldp:membershipPredicate from LDP 1.0 and let's 
> put ldp:membershipPredicate in the wishlist for LDP 1.1.
> 
> R5'.- MUST B
>        (= MUST use rdfs:member)
> 
> Simpler, understandable, testable, and straightforward to implement by 
> clients.
> And, taking into account another relevant factor, this is the one that 
> can lead to a smoother path for application interoperability.

Sure, fewer choices makes interop easier.  Also reduces the number of 
implementations able to even attempt it.

> Note that here we also maintain variability:
> Subject Predicate
> D       B
> E       B
> but this is is something for another discussion: the need to define a 
> clear conformance model for the specification that clearly specifies 
> classes of products covered, variability, etc.

Are you asserting a need in the conformance model for any division beyond 
LDPR/C clients/servers? 


Best Regards, John

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