Martin, I agree that clients should be able to gracefully handle unexpected responses.
Do you disagree with the statement in general, or just when the complications of versioning are considered, i.e. "If a service claims to comply with a domain spec then resources returned by that service must comply with the domain spec" The OSLC Core does have a mechanism for requesting or specifying the version via the OSLC-Core-Version HTTP header. [1] The mechanism allows the service to return a version of a resource that the client can handle. It is therefore meaningful to talk about the version of the service, but this may include support for back-levels of the service too. Even though resources may have been created by different versions of the service, the service has a mechanism for returning a version of a resource that is compatible with the client. I assume that domain specs could define version headers specific to them. [1] http://open-services.net/bin/view/Main/OslcCoreSpecification?sortcol=table;up=#Specification_Versioning Regards, ___________________________________________________________________________ Arthur Ryman, PhD, DE Chief Architect, Project and Portfolio Management IBM Software, Rational Markham, ON, Canada | Office: 905-413-3077, Cell: 416-939-5063 From: Martin Nally/Raleigh/IBM@IBMUS To: Arthur Ryman <[email protected]> Cc: [email protected], [email protected] Date: 12/14/2010 07:08 PM Subject: Re: [oslc-core] Oslc-Core Digest, Vol 11, Issue 24 I think this confirms that the only safe option for a client is to assume nothing. I think the spec should say this. I don't think it's even safe to assume that "the resources that you get from a service that claims to comply with a domain spec must comply with that domain spec". Let's assume I'm a client that is programmed to understand version n of the XYZ OSLC specification. If I access an XYZ service, I might find resources created from version 1 through version n+m of the domain spec stored within the same service, so it probably isn't even meaningful to talk about the version of the service, unless it means simply the version of its service/service provider document. Since I can't know in advance what changes were introduced in versions n+1 through n+m, I can't really say what it means for the resources to be compliant with a spec, so I'd better be prepared for the unexpected. Best regards, Martin Martin Nally, IBM Fellow CTO and VP, IBM Rational tel: +1 (714)472-2690 From: Arthur Ryman <[email protected]> To: Martin Nally/Raleigh/IBM@IBMUS Cc: [email protected], [email protected] Date: 12/14/2010 06:50 PM Subject: Re: [oslc-core] Oslc-Core Digest, Vol 11, Issue 24 Martin, When Jim raised this topic initially, I pointed out that OSLC does not currently make any statement about how type URIs should be used outside their domain specs, i.e. you should assume that the resource satisfies the domain spec. All you can count on is the service, i.e. the resources that you get from a service that claims to comply with a domain spec must comply with that domain spec. However, it does seem natural that the type URIs (and any other property URIs) defined by one domain might be useful to other domains or other non-OSLC services. Since these type URIs are in the OSLC namespace, it seems appropriate that OSLC should specify their intended use, with the usual understanding that no organization can restrict how other organizations use URIs. No, I didn't consider versioning. I assume the versioning rules are specified by each domain and so any user of the type URIs should comply with that. Yes, this could be a can of worms when a resource has more than one type URI since you'd have to specify the versions for each of the domains. This is a great topic for the "Mutli-Type" workgroup to discuss. Regards, ___________________________________________________________________________ Arthur Ryman, PhD, DE Chief Architect, Project and Portfolio Management IBM Software, Rational Markham, ON, Canada | Office: 905-413-3077, Cell: 416-939-5063 From: Martin Nally <[email protected]> To: [email protected] Cc: [email protected], [email protected] Date: 12/10/2010 11:30 AM Subject: Re: [oslc-core] Oslc-Core Digest, Vol 11, Issue 24 Sent by: [email protected] >> the RDF representation of T SHOULD satisfy the OSLC Domain specification that defines T. Have you thought about what this means for versioning? Does this mean the 2.0 version of the OSLC specification? All past and future versions? I think this will open a can of worms. I think we should make the opposite statement - that when something says it is of some OSLC type, this carries no guarantees whatever. Caveat emptor. Best regards, Martin Martin Nally, IBM Fellow CTO and VP, IBM Rational tel: +1 (714)472-2690 From: [email protected] To: [email protected] Date: 12/09/2010 12:00 PM Subject: Oslc-Core Digest, Vol 11, Issue 24 Sent by: [email protected] Send Oslc-Core mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit http://open-services.net/mailman/listinfo/oslc-core_open-services.net or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of Oslc-Core digest..." Today's Topics: 1. Re: Resources that have Multiple rdf:type Values (Arthur Ryman) ---------------------------------------------------------------------- Message: 1 Date: Wed, 8 Dec 2010 17:25:40 -0500 From: Arthur Ryman <[email protected]> To: Dave <[email protected]> Cc: [email protected] Subject: Re: [oslc-core] Resources that have Multiple rdf:type Values Message-ID: <ofbe176e2f.3d444635-on852577f3.007a354b-852577f3.007b3...@ca.ibm.com> Content-Type: text/plain; charset="US-ASCII" Dave, I was pointing out the status quo. However, our desire is that types be used in a predictable way. I am recommending that we add an explicit statement to our spec to avoid "capricious" use of OSLC-defined types. We don't "enforce" this via an ontology so we need to provide explicit guidance in the Core spec. Regards, ___________________________________________________________________________ Arthur Ryman, PhD, DE Chief Architect, Project and Portfolio Management IBM Software, Rational Markham, ON, Canada | Office: 905-413-3077, Cell: 416-939-5063 From: Dave <[email protected]> To: Arthur Ryman/Toronto/IBM@IBMCA Cc: [email protected] Date: 12/08/2010 04:56 PM Subject: Re: [oslc-core] Resources that have Multiple rdf:type Values On Wed, Dec 8, 2010 at 12:22 PM, Arthur Ryman <[email protected]> wrote: > At the Core telecon today, Jim raised this topic. We need to continue the > discussion. Here is a suggestion for how to handle this: > > Any RDF resource representation MAY contain zero or more triples that have > a given URI, S, as the subject, and rdf:type as the predicate, If there > is a triple of the form (S, rdf:type, T) where T is a type URI defined by > some OSLC Domain specification, then the RDF representation of T SHOULD > satisfy the OSLC Domain specification that defines T. I thought you argued against this point today, saying that you can only make that sort of inference when you that a resource is provided by a service that implements an OSLC specification. - Dave ------------------------------ _______________________________________________ Oslc-Core mailing list [email protected] http://open-services.net/mailman/listinfo/oslc-core_open-services.net End of Oslc-Core Digest, Vol 11, Issue 24 ***************************************** _______________________________________________ Oslc-Core mailing list [email protected] http://open-services.net/mailman/listinfo/oslc-core_open-services.net
