[oslc-core] Last changes before going FINAL

[Dave]

I haven't heard any objections so I plan to make these changes today
and I will put "going FINAL" on the agenda for the tomorrow's Core
Workgroup meeting.

Thanks,
Dave



On Tue, May 24, 2011 at 11:40 AM, Dave <snoopdave at gmail.com> wrote:
> Now that OSLC-QM v2 and OSLC-RM v2 have gone final, and are both based
> on OSLC Core v2, I believe we are ready to declare Core v2 FINAL.
>
> But, there are a couple (3) of small changes (below) that would like
> to get in before we do. The three corrections and clarifications below
> came up during IBM-internal reviews of the OSLC Tutorial. I would like
> to propose that we make these changes to Core now, and then move to
> FINAL at our meeting next week.
>
> Does anybody have any thoughts, objections, suggestions or other
> feedback on these changes?
>
>
> *** 1 *** Clarify description of Service Provider Catalog
>
> Reason: Current text is vague about purpose of catalog.
>
> OLD TEXT
> "Service Provider Catalogs are used in the discovery of OSLC Service
> Providers, to simplify the configuration of tools that will integrate
> with providers of OSLC-defined services. These catalogs may contain
> contain other nested catalogs as well as service providers."
>
> NEW TEXT
> "An OSLC implementation that offers one or more Service Provider
> resources (see below), MAY also provide Service Provider Catalog to
> enable OSLC clients to find Service Providers offered. These catalogs
> may contain other nested catalogs as well as service providers."
>
>
> *** 2 *** Correction: don't encourage use of alternative Query Syntax
>
> Reason: Implementations can offer alternative query syntaxes, but we
> don't need to mention that in the Core spec and we definitely should
> not encourage domain workgroups to invent new syntaxes.
>
> REMOVE TEXT (from Query Syntax section)
> "OSLC domain specifications MAY define their own syntax for expressing
> query criteria in a string"
>
>
> *** 3 *** Correction: remove "occurs" column from Common Properties
>
> Reasons: a) when we define common properties we are not defining
> resources, so it does not make sense to specify an occurs value and b)
> we expect domain specifications to decide the right "occurs" value
> when they define their resources.
>
>
> Thanks,
> Dave
>
> --
> David M. Johnson
> OSLC Core Workgroup Lead
> IBM Rational Software
>