Re: Proposal: change following to informative - 5.2.7 thread

> 5.2.7 - rdf (ONLY the portion after the comma; the first clause says 
normative)
> -1 : an LDP client MUST not assume that an LDPC will have a unique type

This is more puzzling.  I guess I need to recap in order to be sure we are 
understanding this the same way.

LC 5.2.7 currently says, in total: 
5.2.7 The representation of a LDPC MUST have rdf:type of ldp:Container, 
but it MAY have additional rdf:types.

So the proposal (being pedantic) might look something like:
5.2.7 The representation of a LDPC MUST have rdf:type of ldp:Container.
5.2.7.1 (non-normative) The representation of a LDPC can have additional 
rdf:types beyond ldp:Container.

The "lost" statement you object to losing (removing indexicals - waves to 
Henry) then is:
The representation of a LDPC MAY have additional rdf:types beyond 
ldp:Container.

This "lost" statement is noticeably different from the one in your 
response, namely "an LDP client MUST not assume that an LDPC will have a 
unique type"; your version is arguably just the flip side.  I'd probably 
agree they're equivalent myself, although I cannot speak for the others in 
the WG.  If we agree they are equivalent, then your version is directly 
asserted in 4.3.5 is it not?

LC 4.3.5 In the absence of special knowledge of the application or domain, 
LDPR clients MUST assume that any LDPR can have multiple values for 
rdf:type. 

You might respond by objecting to the first clause (weasel words) in 
4.3.5; I'd personally have sympathy for removing it in order to accomplish 
the original purpose.  Note that 4.3.5 applies to LDP*R*s, so it covers 
LDPCs as well.  If we get to a place where 4.3.5 covers the ground you are 
concerned about, is there any remaining objection to changing 5.2.7 as 
proposed originally and as restated above?


Best Regards, John

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