[oslc-core] Questions/remarks about the delegated UI for resourceselection
Arthur Ryman
ryman at ca.ibm.com
Mon Oct 17 23:04:44 EDT 2011
Marc,
dcterms:title is more like a brief sentence than a label. If you want a
short label, you could use oslc:name.
Regards,
___________________________________________________________________________
Arthur Ryman
DE, PPM & Reporting Chief Architect
IBM Software, Rational
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile)
From:
Thunissen Marc <marc.thunissen at oce.com>
To:
Steve K Speicher <sspeiche at us.ibm.com>
Cc:
oslc-core at open-services.net
Date:
10/17/2011 11:57 AM
Subject:
Re: [oslc-core] Questions/remarks about the delegated UI for
resourceselection
Sent by:
oslc-core-bounces at open-services.net
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.
_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net
More information about the Oslc-Core
mailing list