oslc-core message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Discovery: Using URLs to web UIs in OSLC configuration (was: Initial discovery (was: OSLC & LDP: Query Capabilities, Creation Factories & location of Dialogs))
- From: Martin P Pain <martinpain@uk.ibm.com>
- To: Steve K Speicher <sspeiche@us.ibm.com>
- Date: Thu, 22 Jan 2015 10:45:36 +0000
Going back to a thread from late last year...
Topic: "Using
URLs to web UIs in OSLC configuration"
In short: In every OSLC (v3+) server,
users shouldn't have to search the config pages & documentation to
find the URL to enter into OSLC clients to connect to that server - it
should be programatically discoverable from whatever URLs the user has
available.
I'll avoid talking about solutions for
now, but I want to bring up again, and attempt to clarify, the problem/story
that I mentioned in the email below in December.
Two stories:
1. Project-scoped
The user has a web-based OSLC-enabled
defect tracking system, which contains multiple "projects". They
also have an OSLC-enabled test tool (desktop app) which they want to configure
to raise defects in the defect tracking system when a test fails. They
open the configuration of the test tool, and it asks for a URL for the
defect tracking system. They already have the defect tracking system open
in a browser (viewing a page in a specific project), so they copy the URL
from the browser's address bar into the configuration of the test tool.
The test tool uses that link to find a container on the defect tracking
system (for the project that the webpage was open at) that accepts defect
resources being created. If it finds multiple such containers it asks the
user which one to use (possibly using a selection dialog for this, if such
a capability is standardised and available). It then stores the URL for
that container in the test tool's project.
In short: using a URL for a web UI page
in a particular project (or some other non-server-wide scope) of the server
to programatically navigate & discover the Url for the desired container.
2. Server-scoped
The same user then opens another project
in the test tool. They want to associate this test tool project with a
different defect tracking system project on the same server. They've already
pasted a URL to a page on the server in to the tool previously (story 1
above), so they don't want to do it again, they want the tool to have remembered
the URL pasted before (at least to make it available when configuring the
test tool project - not using it until the user explicitly asks it to).
However, this time the user wants to navigate "up" out of that
defect tracking system project to select a different project, and then
find a container in that new project the same way as before.
In short: using a URL for a web UI page
in a particular project of the server to programatically navigate to find
other parent or sibling resources/containers on the server.
In addition to these stories, other
concerns are:
- Ideally the user would be able to
do this without the people implementing the server having to think too
much about enabling this use case (chances are: they won't, based on experience
of existing tools)
- I've come across people unwilling
to do content negotiation to serve both RDF and HTML on a Url that was
originally intended to be part of the web UI (e.g. not wanting to rely
on browsers' Accept headers being correct, especially older versions of
IE, and making it hard to browse the RDF by pasting the URL into the browser).
So it would be good to have an alternative, e.g. Link headers.
Possible solutions include:
A. HEAD/OPTIONS with a Link header to
a container for the current page's scope (to navigate up, that container
would either have to have a link to its parent or a "root" container
on the server, or support querying to find a contain which contains the
container it found).
B. HEAD/OPTIONS with both a Link header
to a container for the current page's scope, PLUS a Link header to a "root"
container on the server.
C. Content negotiation for current page's
scope's container, either with a link to parent/root container or a Link
header to a server "root" conatiner. 9This wouldn't work very
well to make it available on every page).
To make this work with EVERY web UI
URL, we would have to make it a "best practise" to expose this
on every page. A compromise might be to only suggest it's exposed on the
server home page and any other page that could reasonably map to a container
(e.g. a project's home page).
But I'm not too bothered about a particular
solution, I'm more interested in having this scenario supported - to improve
the usability of OSLC tools.
Any thoughts on the stories, or on potential
solutions?
Martin
<oslc-core@lists.oasis-open.org> wrote on 09/12/2014
13:54:15:
> From: Steve K Speicher <sspeiche@us.ibm.com>
> To: Martin P Pain/UK/IBM@IBMGB
> Cc: "OASIS OSLC Core TC Discussion List"
<oslc-core@lists.oasis-open.org>
> Date: 09/12/2014 14:05
> Subject: [oslc-core] Re: Initial discovery (was:
[oslc-core] OSLC &
> LDP: Query Capabilities, Creation Factories & location of Dialogs)
> Sent by: <oslc-core@lists.oasis-open.org>
>
> Responses woven in...
>
> > From: Martin P Pain <martinpain@uk.ibm.com>
> > To: Steve K Speicher/Raleigh/IBM@IBMUS
> > Cc: "OASIS OSLC Core TC Discussion List" <oslc-core@lists.oasis-open.org>
> > Date: 12/04/2014 05:27 AM
> > Subject: Initial discovery (was: [oslc-core] OSLC & LDP:
Query Capabilities,
> > Creation Factories & location of Dialogs)
> >
> > This email is about how implementations (or instances thereof)
first
> > interact with each other, concerning discovery of capabilities
and
> resources.
> >
> > I've split this into three sections, but read it as one continuoustrain
of
> > thought. I have other thoughts which I will send in separate
e-mails.
> >
> >
> > "One URL" configuration:
> > ------------------------
> >
> > Story:
> > As a user configuring an integration (e.g. system administrator
or project
> > area administrator)
> > I want to configure the integration between two OSLC-enabled
servers/
> > applications with as few steps as possible (e.g. providing a
single easily-
> > available URL, plus any security config)
> > In order to have the full integration between those two applications
with
> > minimal effort and confusion.
> >
> > At the moment (in v2) OSLC does not seem to do anything to suggestwhat
that
> > "one URL" should be. Something pointing to a oslc:ServiceProviderCatalog
> > might seem to be a good choice. However, most IBM implementations
(including
> > mine) use the Jazz Root Services document [1]. I believe the
main motivation
> > for this is that it is what the Jazz products require, which
is probably
> > because they need the OAuth information and this gives them a
> place to find it.
> >
> In v2, it could be thought that the ServiceProvider (or
> ServiceProviderCatalog to find the SP) is that one 1 URL.
> I think of Jazz Root Services is provide additional triples into
> ServiceProviderCatalog (which is just a container for SPs). There
> is an open work item that is for making it fully a compliant SPC,
it
> is so close.
>
> > Steve, in your proposal, I expect this "one URL" would
point to a container,
> > which can contain other containers to an arbitrary depth to model
the native
> > hierarchy of the server.
> >
> Right, this is basically what v2 has.
>
...
>
> >
> > Using URLs to web UIs in OSLC configuration
> > -------------------------------------------
> >
> > Another problem is getting hold of that "one URL".
Users are generally only
> > aware of the web UI URLs. While it would be perfectly reasonable
for any
> > given implementation to perform content negotiation on their
web UI's
> > homepage's URL to provide an RDF representation of the server
if an RDF
> > media type was requested, I have come across people unwilling
to do that.
> > (e.g. it means you can't stick that URL in a browser to see what
RDF is
> > being returned [although of course there are ways around that]
- which makes
> > exploration of the interface harder, which is how most people
learn).
> >
> These users willing to add response headers or support the OPTIONS
> verb on that URL? Just some other alternatives to sending back
RDF on a GET.
>
> > Story:
> > As a user configuring an integration
> > When asked for a URL to another OSLC implementation, I want to
provide the
> > URL to the web UI of the other implementation (as that is the
URL I know)
> > In order to set up the integration without having to search the
docs for
> > what URL to use.
> > (Extension: "I want to provide the URL for whatever entrypoint/homepage/
> > dashboard I use most in the other tool")
> >
> > We could achieve this by defining a Link header that points to
the root
> > container for that server, which OSLC servers should provide
on: the home
> > page, and any other page that could reasonably be used as an
entrypoint. Or
> > on every page, if they really want to be helpful.
> >
> We'd have to define what a root container is but yes, we could have
> a URL for a place to find configuration/setup information or other
methods.
>
> We used "oslc:details" predicate in v2 to define such a
web ui URL
> from oslc:ServiceProvider
>
> > But what about getting the URL to a particular "leaf"
container
> (e.g. project area):
> >
> > Story:
> > As a user configuring an integration
> > When asked for a URL to a specific project within another OSLC
server (e.g.
> > in a configuration file, such as for a headless operation such
as
> an ant script)
> > Then I want to be able to provide the URL to the web UI for that
project
> > In order to set up the integration without having to search the
docs (or the
> > UI) for what URL to use.
> >
>
> See "oslc:details" from SP from before or conneg.
>
> > We could achieve this by having a separate link header that points
to the
> > container for 'the current scope'. "Project" pages
(or "tenant" pages, or
> > whatever your level of modularity/scope is) would then include
both a link
> > to the root container and a link to their own container.
> > When a URL is given to an interactive process, it could perform
make an HTTP
> > HEAD request on it. If it only has a root container link, it
uses that. If
> > it has both a root container link and a 'current scope' container,
it asks
> > the user which one to use. if it has neither, it performs a GET
to see if
> > the body contains a container (although that should have been
visible from
> > the HEAD too) or to see if it is a V2 catalog, service provider
or service
> > (if v2 compatible).
> >
>
> I guess I'm not following what the problem is here with v2.
>
> - Steve
>
> >
> >
> >
> > [1] https://jazz.net/wiki/bin/view/Main/
> RootServicesSpec#Root_Services_Documents
> >
> >
> > <oslc-core@lists.oasis-open.org> wrote on 02/12/2014 21:40:39:
> >
> > > From: Steve K Speicher <sspeiche@us.ibm.com>
> > > To: "OASIS OSLC Core TC Discussion List" <oslc-core@lists.oasis-open.org>
> > > Date: 02/12/2014 21:40
> > > Subject: Re: [oslc-core] OSLC & LDP: Query Capabilities,
Creation
> > > Factories & location of Dialogs
> > > Sent by: <oslc-core@lists.oasis-open.org>
> > >
> > > I took the liberty to sketch in more detail what I meant
from some
> > > of my comments below. I've put in a webpage how we
can build upon
> > > the LDP Container concept many of the things we depended
on in 2.0.
> > > Requires some new vocabulary as sketched but pretty simple
and
> > > minimal, perhaps even cleanly layers on queryCapability/creationFactory.
> > >
> > > https://wiki.oasis-open.org/oslc-core/Discovery
> > >
> > > Feedback welcome, we can review at upcoming meeting.
> > >
> > > Thanks,
> > > Steve Speicher
> > > IBM Rational Software
> > > OSLC - Lifecycle integration inspired by the web -> http://open-
> services.net
> > >
> > >
> > >
> > > From: Steve K Speicher/Raleigh/IBM@IBMUS
> > > To: "OASIS OSLC Core TC
Discussion List" <oslc-
> > > core@lists.oasis-open.org>
> > > Date: 12/02/2014 08:58 AM
> > > Subject: Re: [oslc-core] OSLC
& LDP: Query Capabilities,
> > > Creation Factories & location of Dialogs
> > > Sent by: <oslc-core@lists.oasis-open.org>
> > >
> > >
> > >
> > > Hi Martin,
> > >
> > > Thanks for sharing. This is timely, as I getting ready
to outline
> > > this in more detail. I have done some work internally
and on my
> > > todo list for this month to publish it out. I'll comment
directly
> > > on some of the points you've raised below.
> > >
> > > - Steve
> > >
> > >
> > > > From: Martin P Pain <martinpain@uk.ibm.com>
> > > > To: "OASIS OSLC Core TC Discussion List"
<oslc-
> core@lists.oasis-open.org>
> > > > Date: 12/02/2014 04:55 AM
> > > > Subject: [oslc-core] OSLC & LDP: Query Capabilities,
Creation
> Factories &
> > > > location of Dialogs
> > > > Sent by: <oslc-core@lists.oasis-open.org>
> > > >
> > > > As we move OSLC 3 to be based on LDP, I presume Query
Capabilities and
> > > > Creation Factories will be replaced by capabilities
from LDP.
> > > >
> > > > As I'm starting to draft the Automation v3 spec, I've
come to the place
> > > > where I need to be able to refer to the definition
of the
> headless query/
> > > > selection and creation capabilities.
> > >
> > > I believe we don't need to define much of this in domain
specs, you
> > > just need to leverage some basic ways that LDP and Core
expose
> > > capabilities and clients can discover it.
> > >
> > > > This also raises the question: are we keeping the existing
> > > > oslc:ServiceProvider and oslc:Service resources? I
see no
> reason not to.
> > > From a pure 3.0 spec perspective, no. I see no reason
to require these.
> > > From a compatibility with 2.0 specs, then yes of course
we'd need to.
> > >
> > > >
> > > > So my expectation of how this would go is:
> > > >
> > > > 1. An oslc:ServiceProvider:
> > > >
> > > > a) which is possibly discoverable
from an
> > > oslc:ServiceProviderCatalog
> > > > b) would contain one or
more oslc:Service resources
> > > We could just have LDP Containers. Perhaps you could
outline the
> > > specific needs of what a oslc:ServiceProvider should have,
so a
> > > client/server could satisfy a certain. Typically the
needs are that
> > > a client needs to interaction with a set of services that
operate on
> > > types of resources, such a container.
> > >
> > > > 2. These oslc:Service resources:
> > > >
> > > > a) would each identify
which OSLC domain they operate in
> > > using their
> > > > oslc:usage property
> > > >
> > > >
i) (I believe this can also exist at the
> > > oslc:ServiceProvider level)
> > > >
> > > > b) Link to LDP containers
for each of the resource types
> > > they work with
> > > >
> > > >
i) (They may have more than one container for
> eachresource
> > > > type, e.g.
> > > >
Automation Requests ready for execution, and
> > > Automation Request
> > > >
templates)
> > >
> > > Essentially, you can think of what a "oslc:Service"
(and everything
> > > it contains) as an LDP:Container, annotated to provide the
needs we
> > > had before (query, dialogs, types, shapes, usage)
> > >
> > > > c) Maybe, they would still
contain the links to the
> > > Creation & Selection
> > > > dialogs (i.e. in the same
place as v2)
> > > Yes
> > >
> > > Something like:
> > >
> > > <> a ldp:DirectContainer;
> > > oslc:creationDialog <#newDialog> ;
> > > oslc:resourceType auto:AutomationRequest.
> > >
> > > <#newDialog> a oslc:Dialog;
> > > oslc:dialog <http://example.org/ui/newDialog>;
> > > dcterms:title "New Automation Request".
> > >
> > > > d) (for providers wanting
to be compatible with v2:) would
> > > contain v2
> > > > Creation Factories and
Query Capabilities
> > >
> > > Correct, we should keep the 3.0 specs "pure" and
have a separate
> > > "note" on v2 compatibility. Imagine what
the 3.0 spec would look
> > > like to someone who knows nothing about v2 or 2 years from
now,
> > > should they know anything about v2?
> > >
> > > There has been some things started and actively being worked
now:
> > >
> > > Core 3.0: http://tools.oasis-open.org/version-control/browse/wsvn/
> > > oslc-core/specs/compat.html
> > > ChangeMgmt 3.0: http://tools.oasis-open.org/version-control/browse/
> > > wsvn/oslc-ccm/trunk/supporting-docs/change-mgt-compatibility.html
> > >
> > > > 3. Those LDP containers:
> > > >
> > > > a) would provide LDP's
querying mechanism. (Is there such
> > > a thing? I
> > > > can't find it.) replacing
v2's Query Capabilities
> > >
> > > No, it is being discussed for LDP "2.0". We
could simply do
> > > something like this to advertise v2 query support on LDP
Containers
> > >
> > > <> a ldp:DirectContainer ;
> > > oslc:queryType <http://open-services.net/ns/core#OSLCQuerySyntax>.
> > >
> > > or something
> > >
> > >
> > > > b) where appropriate, would
provide the creation
> > > capability (replacing
> > > > v2's Creation Factories)
> > >
> > > We could call a LDP Container a creation factory, that is
all it is.
> > > Though I'm not sure if we need to carry that v2 terminology
> forward in 3.0.
> > >
> > > > c) Maybe, it might be appropriate
to link from the
> container to the
> > > > creation & selection
dialogs for the resources in that
> > > container. So
> > > > (for dialogs that are specific
to a single LDP container -
> > > not all will
> > > > be) all the operations
for that container are linked from
> > > the container
> > > > itself. However, compatibility
with v2 would require that
> > > the dialogs
> > > > are linked from the oslc:Service.
> > >
> > > Not sure I'm hearing anything I disagree with but not sure
I fully
> > > get the point. I think it would be helpful if we worked
an example,
> > > side-by-side.
> > > The way to think of it, starting with a Container...build
up from
> > > there like I mentioned before: dialogs, query, etc.
> > >
> > > > In particular, right now I need to know:
> > > > - Is 3a correct, or will we be keeping Query Capabilities?
> > >
> > > For at least 1st half of 2015, I think Query Capability
will remain
> > > a thing only on open-services.net. It is there, we
can use it as
> > > needed. We'll need to decide what we want to do with
this longer term.
> > >
> > > > I think 3c is also an important point to decide on.
> > > >
> > > > Thanks,
> > > > Martin
> > > > 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
> > 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
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]