[oslc-core] domain URL for Service that supports creation/query of Service Provider resources - proposal for review
John Arwe
johnarwe at us.ibm.com
Wed Nov 23 12:23:05 EST 2011
Attached please find a PDF with the draft changes per the enclosed thread
and corresponding Core call.
Best Regards, John
Voice US 845-435-9470 BluePages
Tivoli OSLC Lead - Show me the Scenario
From: Joe Ross/Austin/IBM at IBMUS
To: Steve K Speicher/Raleigh/IBM at IBMUS
Cc: oslc-core at open-services.net
Date: 08/26/2011 10:11 AM
Subject: Re: [oslc-core] domain URL for Service that supports
creation/query of Service Provider resources
Sent by: oslc-core-bounces at open-services.net
Steve,
We would really prefer option (a). although I guess we could use option
(b) informally, until necessary spec work is done. I don't think that we
want to redefine all of the core resource types in another domain.
Even if oslc:domain is not required, there needs to be some property to
allow clients to understand what kind of Service this is. We are planning
to use domain to allow clients to select the Service they want to interact
with.
Thanks,
Joe
================================================
Joe Ross/Austin/IBM, joeross at us.ibm.com
Tivoli Autonomic Computing & Component Technologies
512-286-8311, T/L 363-8311
From:
Steve K Speicher/Raleigh/IBM
To:
Arthur Ryman <ryman at ca.ibm.com>
Cc:
Joe Ross/Austin/IBM at IBMUS, oslc-core at open-services.net
Date:
08/26/2011 08:08 AM
Subject:
Re: [oslc-core] domain URL for Service that supports creation/query of
Service Provider resources
Agree that this sounds like an interesting registry. I also agree that
what the spec says is quite restrictive in the sense of: 1) it doesn't
allow for providers that don't fit any domain and 2) along these same
lines, doesn't allow for pre-spec or proprietary explorations to introduce
"private domains".
To accommodate these two cases, I see 3 different alternatives:
a. Just use the core namespace as Joe suggested
b. Invent a "private domain" namespace and use that
c. Create an OSLC WG, create a spec to support this, then use that
namespace
Doing (a) requires us to modify the definition or intention in the spec,
which I think is the most desirable. Doing (b) has nice qualities but
again would make use issue some changes to the spec. Finally (c) is what
we have today but requires a little overhead.
If there is the possibility of tweaking the spec, not making oslc:domain
required on oslc:Service. Though this has some breaking possibilities
that we should avoid. I believe the other options mentioned provide for
the desired use case without impacting many, if any, clients.
Thanks,
Steve Speicher | IBM Rational Software | (919) 254-0645
> From: Arthur Ryman <ryman at ca.ibm.com>
> To: Joe Ross/Austin/IBM at IBMUS,
> Cc: oslc-core at open-services.net, oslc-core-bounces at open-services.net
> Date: 08/26/2011 08:00 AM
> Subject: Re: [oslc-core] domain URL for Service that supports
creation/query
> of Service Provider resources
> Sent by: oslc-core-bounces at open-services.net
>
> Joe,
>
> Your Service Provider registry service sounds interesting.
>
> I am a little concerned about you using
http://open-services.net/ns/core#
> as the domain since we haven't specified what that would mean. Here is
the
> definition of what a Domain is:
>
> OSLC Domain: an OSLC Domain is one ALM or PLM topic area such as Change
> Management, Requirements management or Automation. Each OSLC Domain will
> have its own OSLC specification that complies with this Core
> specification.
>
> I think we should have a spec that outlines the types of resources in
the
> domain. You have selected just one type of core resource. Perhaps you
> should specify that and coin a URI for it?
>
> Regards,
>
___________________________________________________________________________
>
> Arthur Ryman
>
> DE, PPM & Reporting Chief Architect
> IBM Software, Rational
> Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile)
>
>
>
>
>
> From:
> Joe Ross <joeross at us.ibm.com>
> To:
> oslc-core at open-services.net
> Date:
> 08/25/2011 10:49 PM
> Subject:
> [oslc-core] domain URL for Service that supports creation/query of
Service
> Provider resources
> Sent by:
> oslc-core-bounces at open-services.net
>
>
>
>
> In Tivoli, we are creating a Provider Registry that is itself
implemented
> as a Service Provider (a Service Provider for Service Provider
resources).
> We want to do this, so that we can support creation of Service Provider
> records using a Creation Factory and querying for Service Providers
using
> a Query Capability.
>
> As part of defining the Service, we need to provide an oslc:domain with
> namespace URI. Does it make sense for us to use the OSLC Core namespace
> URI (http://open-services.net/ns/core# ) for this? That seems logical
> since all of the resources we are supporting in this Provider Registry
> Service Provider are defined in the OSLC Core spec.
>
> Thanks much,
>
> ================================================
> Joe Ross/Austin/IBM, joeross at us.ibm.com
> Tivoli Autonomic Computing & Component Technologies
> 512-286-8311, T/L
363-8311_______________________________________________
> Oslc-Core mailing list
> Oslc-Core at open-services.net
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net
>
>
>
>
> _______________________________________________
> Oslc-Core mailing list
> Oslc-Core at open-services.net
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net
_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20111123/77db45f9/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CoreServiceResourceDefinition.pdf
Type: application/octet-stream
Size: 154051 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20111123/77db45f9/attachment.pdf>
More information about the Oslc-Core
mailing list