Having just written a unit test for a "getCompact()" handler, I know
that I would like it if the standard supported the serialization and
marshalling of a Compact from JSON.
As it was, my test serialized the response to string, parsed it back
to Xml Dom, and then investigated the accuracy of the structure with
Xpath expressions. Working with JSON formats of the structure would
have been handy.
Apparently to this tyro, me, a "Compact" is the analog of the
"Catalog" where the latter describes the resource/service URLs for
an Artifact Container and the former describes the resource/service
URLs for a particular resource within the container.
On 4/11/14, 7:40, Samuel Padgett wrote:
Ian,
On discovering the Compact
resource, I'm not sure we've made a decision. I plan to create
a wiki page showing the three proposals. Briefly, here they
are:
1) Custom media type a la OSLC
2.0 - application/oslc-compact+json
2) Link response header - Link:
<http://example.com/bugs/4?compact>; rel="compact"
3) Prefer request header -
Prefer: type=oslc-compact
How you discover the Compact
resource might play into what media types we support.
I think we all agreed the
Compact resource really is a different resource.
--
Samuel Padgett | IBM Rational | spadgett@us.ibm.com
Eclipse Lyo: Enabling tool integration with OSLC
Ian Green1 ---04/08/2014 11:16:03
AM---Hi Martin I thought there had been agreement that
"compact representation" would be
Hi Martin
I thought there had been agreement that "compact representation"
would be a misnomer in v3. Rather, there would be a resource C,
(typically) distinct from R, whose representation(s) could be
used to build a UI preview of R. The minutes [1] echo this -
are the minutes incorrect?
I see the current draft at [2] uses content negotiation to
request the "compact representation". Is the current draft
ahead or behind the meeting decisions (or were these not
decisions at all?)
[1] https://wiki.oasis-open.org/oslc-core/Meetings/Telecon2014.03.20
[2] http://tools.oasis-open.org/version-control/browse/wsvn/oslc-core/specs/resource-preview.html
best wishes,
-ian
ian.green@uk.ibm.com (Ian Green1/UK/IBM@IBMGB)
IBM Rational
<oslc-core@lists.oasis-open.org> wrote on 07/04/2014
17:48:46:
> From: John Arwe <johnarwe@us.ibm.com>
> To: oslc-core@lists.oasis-open.org
> Date: 07/04/2014 17:48
> Subject: Re: [oslc-core] JSON-LD of compact resources
> Sent by: <oslc-core@lists.oasis-open.org>
>
> > 1. Somewhere the consumer gets the URL for the
compact resource,
> > probably through
> > following a link from another resource.
>
> I'm not sure what a "compact resource" is. In the
contributed
> specs, there is simply "a" resource and it either
does/not have a
> compact *representation*.
> There have been past discussions to the effect that the
"compact
> representation" language is incorrect, and it *should be*
a separate
> resource ... is that your meaning? I thought on the call
we agreed
> to stick with the base definitions, but maybe I missed
something.
>
> > 2. It knows, through a specification it was
implemented against
> > (i.e. a resource shape
> > from that spec) that the target of that link is
"likely to be" a
> > compact representation.
>
> The client only knows (sticking with contributed-specs
language in
> this reply) that the resource identified by the URL it
holds might/
> not have a compact representation.
> Even without that critical distinction, in general I'd be
careful
> about implying anything around resource shapes; in our
> implementations it has been 1/n-1 (against resource
shapes, i.e.
> exactly 1 product exposes them out of a dozen-plus).
> > 4ai)IF the resource really is a compact
representation then it
>
> I think that's: If the server returned a compact
representation ...
>
> Which raises a NEW question, if we have >1 compact
representation:
> how does the client know if it got back a compact
representation?
> In the contributed document, there is only one media type
that
> covers both "what it is" semantically and "what syntax
does it use".
> On our espoused path that relation is no longer 1:1, and
the media
> type only conveys the syntax (I assert, given what those
media type
> registrations say).
>
> (and flipping this around) If we allow these json media
types *as a
> way for a client to ask for a compact representation*,
how does the
> server know to send a *compact* representation, vs a JSON
or JSON-LD
> serialization of what a client would receive on a
text/turtle
> request to the same URL? I.e. how does the server know
(given that
> the URL for the "compact representation" and the
not-compact one are
> the same) which the client is really after?
>
>
> Best Regards, John
>
> Voice US 845-435-9470 BluePages
> Tivoli OSLC Lead - Show me the Scenario
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
|