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: [email protected] 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
