[oslc-core] Fw: Issue with the Use of dcterms:title and dcterms:description with oslc:ResponseInfo
Martin Nally
nally at us.ibm.com
Thu Dec 9 19:13:45 EST 2010
Given Ian's observation, it seems pretty clear to me we got this wrong.
What we intended to say is "there are no more pages". What we said instead
is "there may be more pages, but this resource doesn't have any information
on that topic".
Dave, I think you should put this on the list of things to fix.
Best regards, Martin
Martin Nally, IBM Fellow
CTO and VP, IBM Rational
tel: +1 (714)472-2690
From: Martin Nally/Raleigh/IBM
To: Ian Green1 <ian.green at uk.ibm.com>
Cc: Frank Budinsky <frankb at ca.ibm.com>, oslc-core at open-services.net
Date: 12/06/2010 07:03 PM
Subject: Re: [oslc-core] Fw: Issue with the Use of dcterms:title and dcterms:description with oslc:ResponseInfo
Yes, good point, I had forgotten this. To summarize what you are saying in
the simplest way I can think of, if you put "oslc:nextPage = rdf:nil", then
in RDF semantics you are saying explicitly "there are no more pages". If
you simply omit oslc:nextPage, you are saying "the current page resource is
not aware of any subsequent pages, but it's possible that some other
resource knows of one". This distinction may sound a bit pedantic, but we
should decide which one we mean, and do it the right RDF way for that
meaning.
Best regards, Martin
Martin Nally, IBM Fellow
CTO and VP, IBM Rational
tel: +1 (714)472-2690
From: Ian Green1 <ian.green at uk.ibm.com>
To: Frank Budinsky <frankb at ca.ibm.com>
Cc: Martin Nally/Raleigh/IBM at IBMUS, oslc-core at open-services.net
Date: 12/06/2010 12:56 PM
Subject: Re: [oslc-core] Fw: Issue with the Use of dcterms:title and dcterms:description with oslc:ResponseInfo
This relates to the closed semantics that is "suggested" by the RDF
Collections.
Absence of a list property and presence of an empty list are different in
this respect - the former is open, the latter is "closed". Scare quotes
since the closure is by convention, not in the model. However, various
processors (eg Jena ARQ) follow this convention, so it's quite useful.
On a related note: do we think that query results are open or closed? I
think this open/closed question is really about what conclusions can be
drawn from a particular result set. So, for example, would a consumer be
able to conclude "there are no high-priority requirements to work on"
because the result set were empty? Seems silly to ask this question, I
think. But then asking the same question the following day does make sense
since the data may have changed. Does this not mean that, logically, in
terms of the assertions of the RDF model, that the query results are open?
Here we're not modelling "point in time" or "state of the universe", so
this is a moot point - common sense tells us that things change over time.
But if we were to go with the RDF Collections (rdf:List/s-expressions) to
represent query results, we might want to think about this more. One
possibility is to explicitly record query results at some instant: closure
here would make sense.
Another point is that s-expressions don't support reverse iterators - this
might make certain client operations (eg backing up over query results)
clumsier. The use of oslc:next/prev makes this a bit easier.
best wishes,
-ian
ian.green at uk.ibm.com (Ian Green1/UK/IBM at IBMGB)
Chief Software Architect, Requirements Definition and Management
IBM Rational
From: Frank Budinsky <frankb at ca.ibm.com>
To: Martin Nally <nally at us.ibm.com>
Cc: oslc-core at open-services.net, oslc-core-bounces at open-services.net
Date: 06/12/2010 14:41
Subjec Re: [oslc-core] Fw: Issue with the Use of dcterms:title and
t: dcterms:description with oslc:ResponseInfo
Sent oslc-core-bounces at open-services.net
by:
Regarding the rdf:nil issue, I think it has more to do with the value of
the first element than with the next (rdf:rest) value of the last element.
Since rdf collections are general purpose, I can see the possible need for
a distinction between an "empty list" (e.g., myList = rdf:nil) and "no
list" (myList propery missing). That would seem to be the justification for
the collection design.
Do we have a similar use case for paging? That is, do we have a scenario
where we would need to have an explicitly set empty page list? If not, than
the simpler, missing nextPage property, approach might be preferable.
Frank.
(Embedded image moved to file: pic23522.gif)Inactive hide details for
Martin Nally ---12/05/2010 02:06:02 AM--->> there might be other
information associated with an HTTP Martin Nally ---12/05/2010 02:06:02
AM--->> there might be other information associated with an HTTP response
outside the context of paging.
(Embed (Embedded image moved to file: pic59864.gif)
ded Martin Nally <nally at us.ibm.com>
image
moved
to
file:
pic616
05.gif
)
From:
(Embed (Embedded image moved to file: pic18748.gif)
ded Arthur Ryman/Toronto/IBM at IBMCA
image
moved
to
file:
pic246
04.gif
)
To:
(Embed (Embedded image moved to file: pic38085.gif)
ded oslc-core at open-services.net
image
moved
to
file:
pic438
05.gif
)
Cc:
(Embed (Embedded image moved to file: pic46256.gif)
ded 12/05/2010 02:06 AM
image
moved
to
file:
pic268
65.gif
)
Date:
(Embed (Embedded image moved to file: pic15332.gif)
ded Re: [oslc-core] Fw: Issue with the Use of dcterms:title and
image dcterms:description with oslc:ResponseInfo
moved
to
file:
pic413
09.gif
)
Subjec
t:
(Embed (Embedded image moved to file: pic01919.gif)
ded oslc-core-bounces at open-services.net
image
moved
to
file:
pic399
77.gif
)
Sent
by:
>> there might be other information associated with an HTTP response
outside the context of paging.
I don't really understand the mental model behind this statement. I
understand the mental model when I have two different resources,
http://example.com/bugs, and http://example.com/bugs?oslc:paging=true. In
my mental model for this, the second one is also poorly named - it would be
better named http://example.com/bugs?oslc:firstPage, since it is in fact
the first page of the bugs list. In this model, the properties of this
resource are not "information associated with an HTTP response", they are
just regular properties of a regular resource.
>> it's up to the server to decide how to paginate HTML
I'm not sure I understand what you mean. Clients also have to understand
what the server will do, so it would need a spec (unless it's disallowed)
>> oslc:nextPage is more easily comprehended than rdf:rest
Yes, I think that is reasonable. Since you provide a good argument for not
changing this, I'll drop the topic.
>> The explicit use of rdf:nil to signify the last page rather than simply
omitting the oslc:nextPage property means that clients need to understand
the special meaning of rdf:nil
I understand the argument, but that argument applies equally to standard
rdf collections - rdf collections could simply have omitted rdf:next,
rather than setting it to rdf:nil. Even if you are right and the folks who
did the rdf standard were wrong, I think being inconsistent with rdf
precedent does more harm than good and we would do better to fall in line
with precedent.
Best regards, Martin
Martin Nally, IBM Fellow
CTO and VP, IBM Rational
tel: +1 (714)472-2690
From: Arthur Ryman/Toronto/IBM at IBMCA
To: Martin Nally/Raleigh/IBM at IBMUS
Cc: oslc-core at open-services.net
Date: 12/03/2010 12:18 PM
Subject: Re: Fw: [oslc-core] Issue with the Use of dcterms:title and
dcterms:description with oslc:ResponseInfo
Martin,
Sorry for the delayed direct response. Most of these issues have been
addressed in other notes and the spec is an a good state again. Here are my
comments on some of the items in your note
I agree that clients need to understand redirects. I think 302 is OK for
paging, although not a perfect fit. 303 is intended for the case when you
are redirecting to an associated resource. You could argue that the first
page is associated with the requested resource. I think we just need to
pick one, and 302 is OK.
I believe we previously discussed other names for ResponseInfo, including
Page and PageInfo. I recall that the thinking was that there might be other
information associated with an HTTP response outside the context of paging.
As for paging other resources types, it's up to the server to decide how to
paginate HTML. Thinking of HTML as a human-friendly representation of the
RDF data , the way to tie in totalCount is to use RDFa semantics, i.e. the
totalCount applies to the embedded RDF annotations that that full HTML
would carry. In fact, I think we should recommend that when HTML is
requested, that it include the equivalent RDF triples as RDFa.
Concerning RDF Collections, the URIs are rdf:rest and rdf:nil which are
based on classic list processing terminology. Their use to describe a
sequence of pages might seem cryptic to many users. OSLC should use
vocabulary that is natural (c.f. your comments on the cryptic nature of
ResponseInfo), and oslc:nextPage is more easily comprehended than rdf:rest.
The explicit use of rdf:nil to signify the last page rather than simply
omitting the oslc:nextPage property means that clients need to understand
the special meaning of rdf:nil. It is a valid resource, which you can GET
like any other resource, but the special meaning implies that it is not a
valid next page.
Regards,
___________________________________________________________________________
Arthur Ryman, PhD, DE (Embedded image moved
to
file: pic38602.gif)
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 at IBMUS
To: Arthur Ryman/Toronto/IBM at IBMCA
Cc: oslc-core at open-services.net
Date: 11/26/2010 08:24 PM
Subject: Re: Fw: [oslc-core] Issue with the Use of dcterms:title and
dcterms:description with oslc:ResponseInfo
I like where you are going with this. I have a few comments,
clarifications, and questions:
One thing I really like about the direction we appear to be heading in is
that it doesn't require a change to the core spec. Instead we would offer a
clarification/extension that explains what a server should do if it wants
to initiate pagination. The spec already explains what clients need to do.
If the server wants to initiate paging, it could reply with a 302 or 303
redirect, or it could just go ahead and return the first page. Both seem
reasonable - the following link describes and implicitly endorses both
techniques for selecting a representation based on language -
http://www.w3.org/TR/cooluris/#conneg. Selecting non-paginated or paginated
representations based on size is a different case from selecting the
appropriate language representation based on the accept-language header,
but the analogy seems reasonable.
Using a 302 or 303 redirect seems very "classic" to me - it seems very
harsh to try forbid its use. If we allow its use, well-behaved clients have
to anticipate the possibility and code for it. Would you recommend
forbidding the server from using redirect, even though it's a common and
valid solution for these sorts of cases? This question is actually broader
than the current topic of pagination - in the real web, servers can use
redirects whenever they see fit, as described in the link above. The core
spec should probably say whether or not OSLC clients need be ready for
this. My first thought is that they do.
Regardless of the answer to the question on 302/303 redirects, I like your
suggestion that the server should be allowed to return the first page in
response to a GET on the whole list (contrary to what I originally wrote).
If we allow this, I would like us to mandate that the server provide a
content-location header in the response that indicates that the resource
that was returned is in fact http://example.org/bugs?oslc:pagination=true,
not http://example.org/bugs. This gives the client two ways to recognize
what just happened - it can notice that the resource returned is different
from the one requested, or it can look for a nextPage property in the
representation. More generally, it provides the client with a specific
indicator of the "implicit redirect" that happened on the server without
having to guess based on the representation. When we get our verification
test suite going, it should check for this.
Several people have noted that the term "ResponseInfo" does not fit the
conceptual model currently documented in the spec. I think this term is may
be a relic a different conceptual model that was previously proposed and
discarded. Any chance we can change the name to match the model? Page would
be the obvious choice of term.
RDF representations lend themselves very nicely to pagination, because an
RDF graph has no structure - it's just a set of triples, so is easy to
break into subsets. Some other representations, like HTML, are much harder
to paginate, and in fact I find it hard to imagine a satisfactory way to
paginate HTML (maybe 2 pages - one with the head and one with the body).
JSON might also be tricky to paginate. Is pagination only expected to work
with RDF? If so, the spec should say so - I didn't find anything when I
looked. If pagination is expected to work with other formats like JSON, I
think the spec needs explain how to paginate them.
It's not clear what totalCount refers to. Is it simply the number of
triples? The spec says "the number of results", which is a bit vague. I
think we should clarify.
Frank Budinsky pointed out that the sequence of pages is a collection, and
that RDF already has a vocabulary for collections. This would suggest that
we do not need oslc:nextPage - we can use rdf:next instead. Regardless of
whether or not we drop oslc:nextPage, Frank also points out that it would
be more consistent with precedent if the collection was terminated with a
value of rdf:nil for next(Page), rather than absence of the property.
Best regards, Martin
Martin Nally, IBM Fellow
CTO and VP, IBM Rational
tel: +1 (714)472-2690
From: Arthur Ryman/Toronto/IBM at IBMCA
To: Martin Nally/Raleigh/IBM at IBMUS
Cc: oslc-core at open-services.net
Date: 11/26/2010 09:57 AM
Subject: Re: Fw: [oslc-core] Issue with the Use of dcterms:title and
dcterms:description with oslc:ResponseInfo
Martin,
I actually like this alternative. I have some comments.
There are really two different reasons why paging might occur 1) the client
has limitations, 2) the server has limitations. The core spec only is
explicit about the client limitations. If a client does not request paging,
and the result exceeds the server limits, then there are two alternates -
the request can fail, or the server can return partial results and a link
to the rest. I think we'd agree that the later is more friendly and has
precedents. Atom works that way, and so does Insight since it copies Atom.
In both cases there is a specified way to link to the next page without the
client initiating a paging request.
I think our spec should be more explicit, i.e. a client SHOULD always check
for an oslc.nextPage property. If we adopted this, then we wouldn't need
the redirects.
Regards,
___________________________________________________________________________
Arthur Ryman, PhD, DE (Embedded image moved
to
file: pic47446.gif)
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 at IBMUS
To: Arthur Ryman/Toronto/IBM at IBMCA
Cc: oslc-core at open-services.net
Date: 11/25/2010 08:35 PM
Subject: Fw: [oslc-core] Issue with the Use of dcterms:title and
dcterms:description with oslc:ResponseInfo
I do not believe that the problem with the core spec that you describe
exists. I think the core spec is fine in this area and should be left alone
- I think the current design is superior to the one you propose.
Your description says that the problem arises when the user requests
http://example.org/bugs, and the server decides to respond with only the
first page. In the model upon which the core spec is based, this can't
happen. "The list of bugs" and "the first page of the list of bugs" are two
different concepts and are thus two different resources with two different
URLs, and the server does not have the right to respond with the
representation of one when the other was requested. The URL for "the first
page of the list of bugs" is clearly specified in the core spec - it is
http://example.org/bugs?oslc.paging=true. Although the server may not
respond with "the first page of the list of bugs" when the client asked for
"the list of bugs", it might be acceptable for the server to perform a 302
(or 303) redirect if it decided that the requested resource is too big to
return. An argument against this would be that it is unfriendly to surprise
a client that may not understand paging in this way, but on the other hand,
returning an unworkably large representation might be worse and so the
redirect might be the lesser of two evils. If the server did perform a
redirect to http://example.org/bugs?oslc.paging=true, a subsequent GET on
that URL would produce the following representation according to the
current core spec design:
<rdf:RDF xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:dcterms="http://purl.org/dc/terms/" xmlns:oslc="
http://open-services.net/ns/core#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about="http://example.org/bugs">
<dcterms:title>Bug List</dcterms:title>
<rdfs:member rdf:resource="http://example.org/bugs/1" />
<rdfs:member rdf:resource="http://example.org/bugs/2" />
<!-- etc. -->
<rdfs:member rdf:resource="http://example.org/bugs/1000
"/>
</rdf:Description>
<oslc:ResponseInfo rdf:about="
http://example.org/bugs?oslc,paging=true">
<dcterms:title>Bug List - Page 1</dcterms:title>
<oslc:totalCount>10000</oslc:totalCount>
<oslc:nextPage rdf:resource="
http://example.org/bugs/pages/2" />
</oslc:ResponseInfo>
</rdf:RDF>
As you can see there is no problem because the two dcterms:title triples
have different subjects.
Best regards, Martin
From: Arthur Ryman/Toronto/IBM at IBMCA
To: oslc-core at open-services.net
Date: 11/23/2010 12:47 PM
Subject: [oslc-core] Issue with the Use of dcterms:title and
dcterms:description with oslc:ResponseInfo
Sent by: oslc-core-bounces at open-services.net
While reviewing an implementation I noticed that dcterms:title and
dcterms:description can be used with oslc:ResponseInfo. This can lead to
confusion in the case of requesting a any resource, since that resource
itself may use those properties. The resource URI of the first page of a
multi-page response is the same as the URI of the resource itself.
For example, suppose we have a resource that is a list of bugs and that it
has the dcterms:title "List of Bugs". Suppose it contains 10,000 bugs, and
this is too much to return in one response. This resource is like:
<rdf:RDF xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:dcterms="http://purl.org/dc/terms/" xmlns:oslc="
http://open-services.net/ns/core#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about="http://example.org/bugs">
<dcterms:title>Bug List</dcterms:title>
<rdfs:member rdf:resource="http://example.org/bugs/1" />
<rdfs:member rdf:resource="http://example.org/bugs/2" />
<!-- etc. -->
<rdfs:member rdf:resource="http://example.org/bugs/10000"
/>
</rdf:Description>
</rdf:RDF>
Suppose the service will only return 1,000 or less bugs per response. When
you get the bug list URI, the response therefore gets paged. The OSLC Core
spec says that the first page looks something like:
<rdf:RDF xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:dcterms="http://purl.org/dc/terms/" xmlns:oslc="
http://open-services.net/ns/core#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about="http://example.org/bugs">
<dcterms:title>Bug List</dcterms:title>
<rdfs:member rdf:resource="http://example.org/bugs/1" />
<rdfs:member rdf:resource="http://example.org/bugs/2" />
<!-- etc. -->
<rdfs:member rdf:resource="http://example.org/bugs/1000"
/>
</rdf:Description>
<oslc:ResponseInfo rdf:about="http://example.org/bugs">
<dcterms:title>Bug List - Page 1</dcterms:title>
<oslc:totalCount>10000</oslc:totalCount>
<oslc:nextPage rdf:resource="
http://example.org/bugs/pages/2" />
</oslc:ResponseInfo>
</rdf:RDF>
The issue here is that now there are two dcterms:title triples associated
with the subject node <http:example.org/bugs>, which is confusing since
the second one (a child of the oslc:ResponseInfo element) is really the
title of the response.
I can see two fixes. I prefer fix 1 since it cleanly separates the
response info from the request result data.
1. (Preferred) Introduce another property, e.g. oslc:request to identify
the request URI, and use a blank node for oslc:ResponseInfo. The result is
now:
<rdf:RDF xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:dcterms="http://purl.org/dc/terms/" xmlns:oslc="
http://open-services.net/ns/core#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about="http://example.org/bugs">
<dcterms:title>Bug List</dcterms:title>
<rdfs:member rdf:resource="http://example.org/bugs/1" />
<rdfs:member rdf:resource="http://example.org/bugs/2" />
<!-- etc. -->
<rdfs:member rdf:resource="http://example.org/bugs/1000"
/>
</rdf:Description>
<oslc:ResponseInfo>
<oslc:request rdf:resource="http://example.org/bugs" />
<dcterms:title>Bug List - Page 1</dcterms:title>
<oslc:totalCount>10000</oslc:totalCount>
<oslc:nextPage rdf:resource="
http://example.org/bugs/pages/2" />
</oslc:ResponseInfo>
</rdf:RDF>
2. Use different properties for title and description, e.g.
oslc:responseTitle, oslc:responseDescription
<rdf:RDF xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:dcterms="http://purl.org/dc/terms/" xmlns:oslc="
http://open-services.net/ns/core#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about="http://example.org/bugs">
<dcterms:title>Bug List</dcterms:title>
<rdfs:member rdf:resource="http://example.org/bugs/1" />
<rdfs:member rdf:resource="http://example.org/bugs/2" />
<!-- etc. -->
<rdfs:member rdf:resource="http://example.org/bugs/1000"
/>
</rdf:Description>
<oslc:ResponseInfo rdf:about="http://example.org/bugs">
<oslc:responseTitle>Bug List - Page 1</oslc:responseTitle>
<oslc:totalCount>10000</oslc:totalCount>
<oslc:nextPage rdf:resource="
http://example.org/bugs/pages/2" />
</oslc:ResponseInfo>
</rdf:RDF>
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
_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net
(See attached file: pic38602.gif)(See attached file: pic47446.gif)
_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net
[attachment "pic38602.gif" deleted by Ian Green1/UK/IBM] [attachment
"pic47446.gif" deleted by Ian Green1/UK/IBM]
_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic23522.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20101209/7bce6181/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic61605.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20101209/7bce6181/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic59864.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20101209/7bce6181/attachment-0002.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic24604.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20101209/7bce6181/attachment-0003.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic18748.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20101209/7bce6181/attachment-0004.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic43805.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20101209/7bce6181/attachment-0005.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic38085.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20101209/7bce6181/attachment-0006.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic26865.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20101209/7bce6181/attachment-0007.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic46256.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20101209/7bce6181/attachment-0008.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic41309.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20101209/7bce6181/attachment-0009.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic15332.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20101209/7bce6181/attachment-0010.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic39977.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20101209/7bce6181/attachment-0011.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic01919.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20101209/7bce6181/attachment-0012.gif>
More information about the Oslc-Core
mailing list