[oslc-core] Questions/remarks about the delegated UI for resourceselection

[Thunissen Marc]

Hello Steve,

Thanks again for your response.

So a different resource shapes may be provided for the creation factory, query, delegate UI... !
I cannot tell that I like this but this is a solution.

1. I already have a need for the two UI behavior (single and multiple selection):

Multiple selections: 
I create a new test case and I want to link it to the related requirements.
In this case, a multiple requirements selection would be welcome.

Single selection:
I am starting a workflow for which I need a template for some kind of documents.
Such templates are under my asset manager control.
My workflow is not able to run with several templates at once.
In this case, only a single asset selection must be allowed.

2. I don't like this because it means that the server must anticipate all client needs and deliver a dedicated UI for each.
Moreover the client program must know the UI URL because the service provider services cannot make clear (for a program) which UI to use.
The dcterms:title or oslc:label are designed to be readable by humans, not programs.
Only the oslc:usage could be a hint but only the http://open-services/ns/core#default value is defined.

3. dcterms:title is an XMLLiteral.
This is surprising for a form label.
But if there is a specific shape for each UI, we can say that the dcterms:title in this shape must be designed to be a form label.
Nevertheless I don't well understand why there is a shape for the UI, at the same level as the UI url.
The client application need the UI url and, I think, don't need the shape.
The UI implementation don't care about its own URL but could need to use the shape (for a dynamic implementation).

4. Ok.
With different shapes this becomes pretty clear.

Many thanks,

Marc

-----Original Message-----
From: Steve K Speicher [mailto:sspeiche at us.ibm.com] 
Sent: jeudi 13 octobre 2011 22:45
To: Thunissen Marc
Cc: oslc-core at open-services.net
Subject: Re: [oslc-core] Questions/remarks about the delegated UI for resourceselection

Hello,

I have provided some remarks below...

Thanks,
Steve Speicher | IBM Rational Software | (919) 254-0645

> From: Thunissen Marc <marc.thunissen at oce.com>
> To: <oslc-core at open-services.net>,
> Date: 10/12/2011 05:38 AM
> Subject: [oslc-core] Questions/remarks about the delegated UI for
resource selection
> Sent by: oslc-core-bounces at open-services.net
> 
> Hello,
> 
> I have a few remarks about the delegated UI for the resource selection:
> 
> 1.       The specs are unclear about the possibility to select one or 
more resources.
> The explanations are “allow a user to pick a resource” (one resource),
but 
> the example show a response with two resources.
> My feeling about that is that the UI consumer should be able to choose
the 
> preferred behavior: single or multiple selection.
> Can we imagine an option in the UI URI, such as
“oslc.options=singleSelection” or “
> oslc.options=multipleSelection” ?

This is always possible, though I wonder what the scenario is that requires this.  I have not heard the demand for this but do recall it being discussed at one point.

> 2.       As a UI consumer, I also have a need to restrict the resource 
selection.
> I would like to allow the user to select an asset, but only for a
specific asset type.
> By instance we are in a workflow to create a request for tender and I
want 
> to allow the user to select a template for the document to create.
> I could be useful to allow the “oslc.where” in the UI URI.
> Something like and oslc.where=dcterms:type=”Request for tender template” 

> could be a solution.

I would have thought that you could accomplish this by listing multiple oslc:selectionDialogs (one per resource type).  The consumer would pick the right selection dialog based on the desired type.  Does this not work for you as is?

> 3.       A common design pattern is to build the UI on top of the API.
> It could be interesting to be able to create a generic UI layer using 
> metadata coming from the API to build the creation and selection HTML
forms.
> We can use the resource shape, but I cannot find a kind of “display
name” 
> for the properties to create the form labels (and of course we need to
care 
> about the localization).

These are available from resources from their optional oslc:instanceShape reference and from that you can use oslc:Property's dcterms:title
See: 
    
http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA#OSLC_Properties
    
http://open-services.net/bin/view/Main/OSLCCoreSpecRDFXMLExamples#Shape_Resources

> 4.       I have some oslc resources for which some properties must be 
> specified when creating a new resource but cannot be changed later.
> I am not sure how to declare this in the shape.
> Should I have to write “oslc:readOnly=true”, “oslc:occurs=http://open- 
> service.net/ns/core#Exactly-one” and no “oslc:defaultValue”.
> But there are also some resources, such as the “dc:identifier”, that 
> can

> neither be set at creation time nor changed later.
> How can I mark the difference in the shape (still trying create the UI
> automatically) ?

Yes would need different shapes for different purposes

For the shape associated with the creation factory, setup the requirements
as:
   “oslc:readOnly=false”,
“oslc:occurs=http://open-service.net/ns/core#Exactly-one” and no “oslc:defaultValue”

Then for the query and/or instance shapes do this:
   “oslc:readOnly=true”,
“oslc:occurs=http://open-service.net/ns/core#Exactly-one” and no “oslc:defaultValue”
(mark readOnly as true)



This message and attachment(s) are intended solely for use by the addressee and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law.

If you are not the intended recipient or agent thereof responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited.

If you have received this communication in error, please notify the sender immediately by telephone and with a 'reply' message.

Thank you for your co-operation.