Re: Issue-71: the first bug tracking example

El 30/05/13 22:34, John Arwe escribió:
>  > That's totally my point: the specification is not correct as is.
>
> That is not what I said.  Tortured = hard to reliably interpret as
> intended.  "not correct" = applying the rules as stated leads to results
> *other than* the intended ones.  It might be both though.
> If R1' doesn't force any behavior, then it allows B or !B.
> B => C or !C
> !B => C
> Presumably since you like the B XOR C formulation, you see no problem
> with B && !C or !B && C, so we'll put those aside.
>
> B&&C  might be consistent (both rdfs:member ... redundant, but
> consistent) or not (values disagree).  I read 5.2.4 to say that (when
> present) the ldp:membershipSubject fully determines the membership
> triples' subject URI; 5.2.5 lacks the equivalent final sentence from
> 5.2.4, which looks "not correct".  If they both had that sentence, I'd
> say correct in the end but still tortured.
>
>  > > You've lost the current recommendation (SHOULD) to use rdfs:member, or
>  > > your re-write is incomplete when it omits R1'.
> ...
>  > That change eliminates any ambiguity that the SHOULD brings, supports
>  > the different use cases mentioned in this mailing list, and allows
>  > defining a concrete test.
>
> That 'should' really belongs in the deployment materials, it's for (yes,
> newbie) ontologists.
> We've seen people who feel bad if they don't use Absolutely Every
> Feature in specs they exploit, even if they don't need to.
>
>  > In prose (omitting the three fist sentences that simply describe the
>  > requirements below):
>  > 5.2.3 An LDPC representation MUST either use the rdfs:member predicate
>  > or contain one triple with the ldp:membershipPredicate or
>  > ldp:membershipPredicateInverse predicate when the membership predicate
>  > comes from the server application vocabulary. An LDPC representation
>  > MUST NOT use as membership predicate both rdfs:member and
>  > application-specific membership predicates.
>
> Generally works for me.  I think the original could be adjusted too, no
> strong preference since I think the intent is fundamentally the same.
> Weeding out the deployment guidance is a Genuinely Useful Result in my
> mind whether or not the rest changes.

Well, if it could work for you, and the current "tortured" text should 
also be changed, I propose to update the specification with the XOR 
option, unless someone else disagrees.

>  > I am asserting the need for a conformance model. :)
>
> I actually thought we had an open issue for that, but checking the
> archives I see that -31 and the matching editors action -31 have closed.
>
>  > As an example, from your sentence, in your mind the specification is
>  > covering four classes of products: LDPR clients, LDPR servers, LDPC
>  > clients, and LDPC servers.
>
> Actually, I was intending to assert nothing beyond the client/server
> distinction.  I intended to expose our loose language, since I have
> observed myself people saying all 4 (most commonly, R/C "server" pair).
>   Prior to the submission I whined about it enough to get the language
> changed to levy requirements predominantly on implementations (client or
> server, I don't care, just be clear which) ... I tried for exclusively
> but things like that rdfs:member guidance (SHOULD) persisted in spots.
>   As you might imagine, resolving issue 32 requires nailing this down too.
>
>  >  From my point of view the specification does not cover clients (i.e.,
>  > we are not defining at all the behaviour of clients with the current
>  > requirements in the specification, and we have no concrete use cases for
>  > clients or test cases).
>
> I'm pretty sure we do make one or two, MAYs IIRC, to render some
> implications explicit.  We found that devs writing clients were not
> always picking out the implications for client behavior for some
> scenarios when it was phrased only as server-side language.  Example: a
> GET-PUT round trip to update something when PATCH is not implemented -
> client should preserve content it does not recognize.  Maybe zero of
> those have survived this far, not sure.

Yes, there are a couple about that.

The point is whether they should be in the specification (which would 
require defining test cases for them and showing that at least two 
implementations satisfy them) or they should be part of the deployment 
guide.

>  > The point is not whether one of us is correct or not, but that two
>  > different persons have different interpretations. And this does not
>  > impede another person to come with a third one.
>
> With you in theory; in practice I 80-20 it (some say at best I 95-5 it,
> but still...).
>
>  > That's where I see the need for a conformance model.
>
> I thought -31 was still open (implicit WG +1 in that case), but since
> it's not open +1 to that.

Good. :)

-- 

Dr. Raúl García Castro
http://delicias.dia.fi.upm.es/~rgarcia/

Ontology Engineering Group
Departamento de Inteligencia Artificial
Universidad Politécnica de Madrid
Campus de Montegancedo, s/n - Boadilla del Monte - 28660 Madrid
Phone: +34 91 336 36 70 - Fax: +34 91 352 48 19

Received on Friday, 31 May 2013 06:41:51 UTC