[Oslc-Automation] "Findings" in Availability spec, that also appear in the Automation 2.0 spec

Thu Jul 17 10:46:50 EDT 2014

Hello,

going through your comments to the Availability spec,
there are some "findings" on things that I just copied over from the Auto
spec 2.0 (and replaced auto with availability) and therefore possibly
should be corrected there as well (or flow into Auto spec 2.1)?

These are the "findings":

(1) Section "Introduction": "mime type handling". MIME is written in lower
case, but should be upper case.

(2) Section "Automation Resource Definitions": "For all resource types
defined in this specification, all required properties (those defined with
an occurrence of exactly-one or one-or-many) MUST exist for each resource
and must be provided when requested."

John's commented in the Avail spec draft to this: "Create requests often
have looser restrictions." I'm not sure how to interpret this. @John, do
you mean that I should just remove this sentence? Or make a "SHOULD exist
for each resource" out of it?

(3) Section "Resource XYZ", dcterms:identifier. Description is "A unique
identifier for a resource. Assigned by the service provider when a resource
is created. Not intended for end-user display."

John mentioned "any time you see the word 'unique', you need to qualify it
w/ some scope (of uniqueness).". I copied this description for the Avail
spec draft. I can't remember that I see any scope definition for uniqueness
in the Auto spec. Or did I miss it?
Besides that I think the concept of "unique identifier" is very common. Do
you really think I need to specify something like a "unique proceeding
number" or so?

(4) Section "Automation Provider Sub-Domains":
Quote: An instance of an OSLC Automation service provider might provide
services for one or more particular automation sub-domains (e.g. test or
build automation). Automation service providers MAY declare sub-domain
information in the Service Provider document by specifying a sub-domain
value in the oslc:usage attribute on the oslc:Service resource in the
Service Provider document. Valid sub-domain values are:

John's comment: ":usage is permitted at other places in the SP
representation; not sure if you're attempting to constrain what Core allows
here, or not.  if not, this could be read to constrain core so you need to
tweak; probably pointing to core instead of re-stating a subset of it."

(5) Section "Automation Provider Sub-Domains":
Quote: An automation service provider which is a general-purpose automation
provider, or a provider not wanting to provide a sub-domain should provide
an oslc:usage value of http://open-services.net/ns/auto. If no oslc:usage
attribute indicating a sub-domain is present, the default is assumed to be
http://open-services.net/ns/auto.

John's comment: "NO.  The NS URI identifies *the namespace*, so you cannot
also use it for this.
Generally in RDF the convention is to avoid creating
placeholder "null" values - if something is not known, the absence of an
assertion is sufficient."
So what's the right solution here. Use "
http://open-services.net/ns/core#default " as specified in CORE?

(6) Section "Automation Service Provider HTTP method support", column
labeled "JSON".

John's comment: "*which* JSON ?  Core 2 was written before JSON-LD existed;
since you're in RDF space, you probably want that.  OSLC-JSON has known
limitations, as Maximo found out.
If you want JSON-LD, do you care about
profiles or variants (the Rec has 3 variants defined - I think you want to
require compact format if JSON-LD is supported at all, fwiw)".

Mit freundlichen Grüßen / Kind regards

Tim Friessinger

System Automation for z/OS Development
IBM Software Group, Tivoli
IBM Lab Boeblingen, Germany

 Phone:            49-7031-16-2535                IBM Deutschland                            (Embedded 
                                                                                           image moved 
                                                                                              to file: 
                                                                                         pic60375.gif) 

 E-Mail:           tfriess at de.ibm.com             Schoenaicher Str. 220                                

                                                  71032 Boeblingen                                     

                                                  Germany                                              

 IBM Deutschland                                                                                       
 Research &                                                                                            
 Development                                                                                           
 GmbH /                                                                                                
 Vorsitzende des                                                                                       
 Aufsichtsrats:                                                                                        
 Martina Koederitz                                                                                     
 Geschäftsführung:                                                                                     
 Dirk Wittkopp                                                                                         
 Sitz der                                                                                              
 Gesellschaft:                                                                                         
 Böblingen /                                                                                           
 Registergericht:                                                                                      
 Amtsgericht                                                                                           
 Stuttgart, HRB                                                                                        
 243294                                                                                                

-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic60375.gif
Type: image/gif
Size: 1851 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20140717/6047ca5c/attachment.gif>