-
Type:
Improvement
-
Status: Applied
-
Priority:
Minor
-
Resolution: Fixed
-
Component/s: None
-
Labels:
-
Proposal:
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.
I have another suggestion for this, which I think has none of the drawbacks of the other options. The only drawback is that it requires string parsing for any use other than in HTML5.
My suggestion is to create a new property on the compact resource/representation called "oslc:iconSrcSet" and borrow HTML's img element's srcset attribute's format. For example:
<>
oslc:icon <mediumIcon.png>;
oslc:iconSrcSet "smallIcon.png 16w, mediumIcon.png 32w, largeIcon.png 64w".
which is making 3 icons available: one with a width of 16px, one of 32px and one of 64px. (The spec allows for heights in the parsing algorithm, but as a future compatibility measure - so they technically cause a parse error. We could either say we allow heights despite that, or say that clients should not throw an error if they see them, for future compatibility.) Plus in this example the server is identifying mediumIcon.png as the fallback for OSLC v2 clients, or OSLC v3 clients who don't want to parse the iconSrcSet value.
There is a blog post about this srcset format here (ignore everything about the sizes attribute, I believe that would not be a concern of the OSLC server):
https://css-tricks.com/responsive-images-youre-just-changing-resolutions-use-srcset/
For use directly in HTML5 pages, the browser compatibility is quite good:
http://caniuse.com/#search=srcset
For use in desktop apps or other contexts, the string would have to be parsed. The format is described in the "HTML Living Standard" (aka HTML5... kind of...):
https://html.spec.whatwg.org/multipage/embedded-content.html#the-img-element:attr-img-srcset-2 (for the complete description, you will also have to follow the "image candidate string" link).
as well as the parsing algorithm:
https://html.spec.whatwg.org/multipage/embedded-content.html#parse-a-srcset-attribute
I don't want to spend too long on this, but given it is an existing standard to describe an set of images that are the same except for their size, it seems like a good fit what what we're doing. Especially as I expect many uses of these icons will be in the web pages. But do you all think the potential burden for non-HTML clients is too much?
This looks like a good suggestion - it addresses the need, doesn't introduce a backward compatibility problem, and uses existing solutions that are likely already implemented in some clients. I don't find the string parsing to be a barrier or significant burden.
Agreed.
TC approved: Use new property oslc:iconSrcSet in addition to oslc:icon when a list of icon sizes is available on the server 2015,.10.01.
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.