[OASIS Issue Tracker] (OSLCCORE-15) Allow client to request different icon sizes for resource preview

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/OSLCCORE-15?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=60573#comment-60573 ] 

James Amsden commented on OSLCCORE-15:
--------------------------------------

From our TC call today, we raised some issues and potential resolutions on this proposal. Here's a summary that hopefully is sufficient to inform an electronic vote on the proposal.

Clause: Clients can specify the preferred icon size using the Prefer: return=representation; include="http://open-services.net/ns/core#PreferCompact”; with additional parameter iconsSize whose value is  expressed in length units specified in [CSS21].

Clause: Icons MUST be square. Servers SHOULD provide icons with sizes: 16px, 24px, 32px, 48px, and/or 64px.

Clause: The server SHOULD return the an icon of the requested size, or the largest icon available that is smaller than the requested size

Add property oslc:icons to the Compact resource whose value is a list of URIs to available icons with property oslc:icon the default icon.

Issues:

1. OSLC Compact resource shape oslc:icon property is zero-or-one, and has no size property. So the icons available are not currently discoverable. Changing a property from zero-or-one to zero-or-many would be OSLC2 client breaking because the client would be getting a collection of icon URIs when they are expecting one. A new oslc:icons property would be required while oslc:icon might contain the default icon.

Resolution: create a new oslc:icons Compact resource property, and leave oslc:icon as the “default” icon.

2. The server returns the largest icon available that is smaller than the requested size assumes client will fit the icon into the available space without scaling it. If clients would be expected to scale the icon, then the smallest icon that is larger than the requested size should be returned since large icons generally scale down better than small icons scale up. However, not all icons are scalable, and the client wouldn’t know this until after they got the icon.

Resolution: the most conservative thing to do is to return the largest icon smaller than the requested icon size as this will fit into the available space without requiring scaling (which may not be possible).

3. If we included a Compact::iconSizes property, the order of the icons sizes would have to be the same as the order of the icons. Order of property values is not something that should be relied upon. Either this property would have to be removed and calculated from the icon, or we would need to introduce an IconDescriptor class that contained the icon URL and icon size.

Resolution: don’t store oslc:iconSize, if clients need it they can use HEAD to discover the available icon sizes. This may not be very practical though since that would be a lot of HEAD requests to figure out what’s available just to get a preview icon, an operation that should be as fast as possible.

4. The optional parameters on a preference should be registered in this registry: http://www.iana.org/assignments/http-parameters/http-parameters.xhtml#preferences as described here: http://tools.ietf.org/html/rfc7240#section-5.1
LDP defines the "include" and "omit" parameters here: http://www.w3.org/TR/2015/REC-ldp-20150226/#prefer-parameters. These do not appear to be registered.

Resolution: don’t worry about it if W3C didn’t for LDP.


> Allow client to request different icon sizes for resource preview
> -----------------------------------------------------------------
>
>                 Key: OSLCCORE-15
>                 URL: https://issues.oasis-open.org/browse/OSLCCORE-15
>             Project: OASIS OSLC Lifecycle Integration Core (OSLC Core) TC
>          Issue Type: Improvement
>            Reporter: Nick Crossley
>            Priority: Minor
>              Labels: ready-for-vote
>
> In OSLC Core 2.0, the icon referenced from a compact resource SHOULD be 16x16 pixels. In the current OSLC 3.0 draft, this recommendation is removed, and the size is unspecified.
> The OSLC 2.0 approach is too restrictive, and the OSLC 3.0 approach too vague. The client should have some way of suggesting the desired size. 
> OSLC3 should provide some means for the client to request a specific icon size for resource preview.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)