[oslc-core] Indexing/ChangeLog resources

[Frank Budinsky]

> > The current version of the proposal does a better job at meeting goal
#2
> > than #1. It says this:
>
> Which #1 and #2.  I see nothing labeled with those strings earlier
> in your message, nor the word "goal" or any spelling variant.

It sounds like somehow the message that your received may have been
corrupted. Just before this sentence it says:

The second question, "how are they exposed", is more interesting. Two goals
for this design have been identified during design discussions so far:
   1. Decouple this as much as possible from the OLSC service discovery
      model
   2. Make it possible to leverage/reuse OSLC Query Capabilities, if they
      are available

They're really just "informal design objectives" that have come up in
previous email discussions or during the OSLC WG meetings.

> This set of alternatives appears to ignore a third case, i.e.
> multiple Query Capabilities are exposed and their set of enumerated
> resources overlap.  Or is that not relevant for some reason?

I was thinking that it wouldn't matter, other than for performance, if
there was some overlap, as long as every resource in the "complete set" is
returned at least once. However, I guess you do bring up a good question
because the spec should probably say whether or not any overlap of the
"identified public Query Capabilities" is allowed. Either way, it would
still be fine to have other Query Capabilities that do overlap.

Thanks, Frank.

oslc-core-bounces at open-services.net wrote on 03/28/2011 07:39:11 AM:

> [image removed]
>
> Re: [oslc-core] Oslc-Core Digest, Vol 14, Issue 30
>
> John Arwe
>
> to:
>
> oslc-core
>
> 03/28/2011 07:39 AM
>
> Sent by:
>
> oslc-core-bounces at open-services.net
>
> Forgive me, but I'm confused.
>
> > The current version of the proposal does a better job at meeting goal
#2
> > than #1. It says this:
>
> Which #1 and #2.  I see nothing labeled with those strings earlier
> in your message, nor the word "goal" or any spelling variant.
>
> > In the simplest case, a service provider can provide exactly one Query
> > Capability (i.e., queryBase URI) which includes all of its contained
> > resources. On the other hand, it may instead provide several Query
> > Capabilities, each exposing only a subset of the indexable resources.
This
> > is convenient if different types are most easily returned using custom
> > member properties.
>
> This set of alternatives appears to ignore a third case, i.e.
> multiple Query Capabilities are exposed and their set of enumerated
> resources overlap.  Or is that not relevant for some reason?
> Best Regards, John
>
> Voice US 845-435-9470  BluePages
> Tivoli Component Technologies
>
>
> _______________________________________________
> 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/20110328/72db5a03/attachment-0003.html>