Steve,
I think each spec needs to make it clear how to interpret the tables that
appear in that spec. However, the semantics of ResourceShape are defined by
OSLC Core and therefore any use of ResourceShape MUST conform to the OSLC
Core spec. We should also have some Best Practice guidance to the effect
that the tables that appear in any spec SHOULD be consistent with the
semantics of ResourceShape, and any difference MUST be clearly stated in
the spec that includes the table.
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: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|06/01/2012 11:29 AM
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Re: [oslc-core] Fw: what is the actual intent of resource definition
table columns? |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
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
