Just to be clear. We are saying the tables in the specs are a SHOULD The runtime per supported operation fetched shape MUST follow the rules of resource shapes (which we agree are a bit weak, plan to tighten up with SPARQL ASK semantics)
Agree? Thanks, Steve Speicher | IBM Rational Software | (919) 254-0645 From: Arthur Ryman/Toronto/IBM@IBMCA To: Steve K Speicher/Raleigh/IBM@IBMUS, Cc: [email protected] Date: 05/15/2012 02:32 PM Subject: Re: [oslc-core] Fw: what is the actual intent of resource definition table columns? Steve, Thx for the clarification. Regards, ___________________________________________________________________________ Arthur Ryman DE, Chief Architect, Reporting & Portfolio Strategy and Management IBM Software, Rational Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) From: Steve K Speicher/Raleigh/IBM@IBMUS To: Arthur Ryman/Toronto/IBM@IBMCA Cc: [email protected] Date: 05/15/2012 02:12 PM Subject: Re: [oslc-core] Fw: what is the actual intent of resource definition table columns? I don't think we are far off from saying the same things. I tried to elaborate a bit below.... > From: Arthur Ryman/Toronto/IBM@IBMCA > To: Steve K Speicher/Raleigh/IBM@IBMUS, > Cc: [email protected] > Date: 04/20/2012 02:31 PM > Subject: Re: [oslc-core] Fw: what is the actual intent of resource > definition table columns? > > Steve, > > My reply is [1]. I think I disagree with you. > > For Example 2, the occurence constraint is one or many. Therefore zero is NOT allowed. I agree. I just misread it as zero-or-more > For Example 3, Either means that both representations are valid, i.e. the > resource is "inlined" or just references via URI. Both client and server > must be able to handle both representations. Ok, we are arguing over MUST or MAY on this one. So I agree that when a server advertises its support via the resource shape then it MUST support this. I was taking the original "informative" approach to tables within the specification, which I do not think we can treat as a MUST. > > [1] http://open-services.net/pipermail/oslc-core_open-services.net/2012- > April/001299.html > > Regards, > ___________________________________________________________________________ > > Arthur Ryman - Steve
