Presentation URLs from Resource URLs

1. Presentation URLs from Resource URLs Last updated Sep. 22, 2008

2. UI Client’s Problem • Clients obtain URLs to JTS data resources • Directly • Embedded as links in other data resources • Clients know how to work with and present some data resources • E.g., work item GUI editor can read, manipulate, and present work items • Clients have little/no knowledge of other data resources • E.g., work item GUI editor does not know anything about test cases • Data resources are linked to other data resources • E.g., a work item resource is linked to a test case • UI clients need ways to provide users with smooth navigation between presentations of linked resources • Web UI presentations • Desktop presentations • … • Most data resources are not directly presentable to users • Represented as XML documents • UI clients must be able to discover how to present other data resource • Discover suitable presentation given URL of a data resource • Be able to presentation coming from resource’s home tool • Choose from what’s available • Bring up chosen presentation of data resource

3. Two sides of coin • Outside – UI clients interact with JTS to discover and bring up presentations • As long as client gets a good answer, client doesn’t care how answer is computed • Inside - How does JTS come up with answers? • What are the internal mechanisms? • Matters might • Both are needed • Largely separable • Outside is more straightforward

4. Straw man proposal in 2 parts • Provider Discovery Service • General service used for various purposes • UI clients use to find presentations for a data resource • Addresses client’s needs - outside • Provider Registry • General registry used internally to associate information providers with a data resource • UI presentation providers associate presentations • Addresses implementation concerns – inside

5. What do UI clients know? • UI client has URL in hand • UI client is interacting with a particular JTS • Presumptively URL is of data resource on that JTS • UI clients need not know • Whether data resource actually exists • Whether data resources is actually on a JTS • Whether data resources is actually on that particular JTS • What type of presentation are of interest (although it helps) • Content type of data resource (presumptive or actual) • Process governing the data resource • That is to say – NOT MUCH

6. What do UI clients need? • UI client has URL of data resource in hand • Wants to show the referenced data resource to their user…somehow • Appeals to a particular JTS for recommend presentation(s) of certain type(s) • JTS will answer with options • List of available presentations for data resource • Which types of presentation are available • Presentation provider label for displaying choice to user • Information on how to call up that presentation • Preferred presentation • Explain in cases where it cannot help • Data resource has no known presentations • Data resource is on some other JTS • Data resource is not on a JTS • Temporarily unable to decide (e.g., unable to “sniff” data resource) • UI client chooses from available presentations • Present options to user and let them pick • UI client calls up the chosen presentation for data resource • Could involve launching desktop app • Could involve directing web browser to different web page • Could involve …

7. Straw man proposal part 1 – Provider Discovery Service • Provider Discovery Service • REST-based API • Part of JFS • Useful for finding presentations (and likely much, much more) • Globally available • One per JTS • Assume base URL discoverable via other JFS discovery service • http://{JF-server}/find-providers?types={entry-types}&url={data-resource}&all=true • UI client • Discovers base URL of Provider Discovery Service • Constructs request URL by filling in • URL of data resource in question • 1 or more entry type IDs for presentations of interest to client: jazz.webui, jazz.richui • Make GET request • Response is list of recommended (or all available) presentations for data resource • Presentation type - e.g., jazz.richui • Presentation provider label - e.g., “RTC Client” • Preferred: yes • Presentation URL - e.g., “rtc:rtc1/u” • Chooses from available presentations • Uses presentation URL to bring up presentation

8. Client accessing rich UI presentation RRC Client jf1 – JFS rtc1 – RTC server GET /find-providers?types=jazz.webui,jazz.richui&url=//rtc1/u i.e., Find all presentations for //rtc1/u 1 ? 2 <xml> ( jazz.webui, “Build Web UI”, N, http://b1/show-build?//rtc1/u ) ( jazz.richui, “RTC Client”, Y, rtc:rtc1/u ) 3 User chooses rich presentation RTC Client 4 GET rtc:rtc1/u 5 Launches desktop app 200 OK 6 Retrieve build result /u Build result data 7 Shows data in Build Results view

9. Client accessing web UI presentation RRC Client jf1 – JFS rtc1 – RTC server GET /find-providers?types=jazz.webui,jazz.richui&url=//rtc1/u i.e., Find all presentations for //rtc1/u 1 ? 2 <xml> ( jazz.webui, “Build Web UI”, N, http://b1/show-build?//rtc1/u ) ( jazz.richui, “RTC Client”, Y, rtc:rtc1/u ) 3 User chooses web presentation b1 – Presentation provider GET /show-build?url=//rtc1/u 4 GET /u <xml> i.e., raw build result data 5 6 <html> i.e., computed page presenting build result data 7 Shows data in browser widget

10. Straw man proposal part 2 - Provider Registry • Assume that data resource and services are fundamental • REST APIs are for ALL clients – not just for ones with UIs • Presentations depend on data resources • Not the other way around • Not all data resources will even have presentations • Additional presentations can be added as easily as the first • NEEDED: mechanism for associating presentations with data resources • Presentations are typically geared for resource with a particular content type • E.g., RRC Client can present requirement resources • Presentations are sometime geared for resources with a particular content type living in a particular repository • E.g., DOORS client presents requirement resources in a DOORS repository • Express with a set of declarative selection rules • “The DOORS Client can provide a rich UI type presentationfor data resources with content type X-application/oslcrequirement+xmlThe corresponding presentation URL is computed from the data resource URL by …” • JTS maintain global set of rules in provider registry

11. Provider registry • Provider registry consists of selection rules, including ones for presentations

12. How Provider Discovery Service is implemented • Input from client • Data resource URL • List of entry types of interest • Best vs All • Use HEAD to “sniff” data resource URL • http headers reveal • Content type of resource • JTS server that hosts data resource (i.e., basis of JFS Discovery) • Determine all applicable selection rules in provider registry • Match Entry Type :: entry types of interest (input) ANDmatch Content Type Pattern :: data resource content type (step 2) • Compute one tuple for each applicable rule • (Entry Type, Provider Label, Preferred, x) wherex = f(data resource URL) and f is given by URL Transformation Function • Sort results • Within entry type, sort by preferred, more-to-less specific • Choose best result per entry type (unless “all” specified) • Return to client • List of tuples

13. Client accessing web UI presentation RRC Client jf1 – JFS rtc1 – RTC server GET /find-providers?types=jazz.webui,jazz.richui&url=//rtc1/u i.e., Find all presentations for //rtc1/u 1 HEAD //rtc1/u 3,4,5 2 Content-Type: X-app/oslcbuild+xml X-JTS: … Other useful headers? <xml> ( jazz.webui, “Build Web UI”, N, http://b1/show-build?//rtc1/u ) ( jazz.richui, “RTC Client”,Y, rtc:rtc1/u ) 6 User chooses web presentation b1 – Presentation provider GET /show-build?url=//rtc1/u GET /u <xml> i.e., raw build result data <html> i.e., computed page presenting build result data Shows data in browser widget

14. Where does info in registry come from? • Registry is exposed though system-defined resource • Discoverable through other JFS discovery services • Representation is a single XML-based data resource • Selection rules are XML subelements • Selection rules • Largely contributed by JTS extensions at their install time • Tweakable by system administrator • Requires high administrative permissions to update

15. URL transformation functions • URL-to-string transformations are described by input pattern and output tempate • E.g., function http://{host}/{path} -> http://jf1/webui/user/{host}/{path}input http://example.com/users/zoeoutput http://jf1/webui/user/example.com/users/zoe • Simplest possible things that could possibly work • Simple • Flexible • Declarative – describing novel xmf does not require adding code to server • Note: Interesting information in data resource URL must be encoded (somehow) in presentation URL • Presentation provider must be able to reconstruct data resource URL given only presentation resource URL • If it cannot, presentation provider would need more expensive query to locate data resource URL

16. Design Assumptions and Issues • Information on how to call up rich and web presentations can be expressed conveniently as URL • HTTP for standard web presentations • E.g., http://b1.eg.com/show-build?data=//rtc1.eg.com/u • Non-standard URL schemes for launching desktop applications (like “mailto” scheme) • E.g., rtc:rtc1.eg.com/u • Is this reasonable? • Tool-specific tagging of resource content type • Assuming that tools will tag their resources’ content type with tool ID • E.g., needed to ensure a requirement in a DOORS repository will be shown with a DOORS presentation • Generalization • Clients asks for presentations for particular data resource – not resource type • User chooses from available presentations and indicates “Remember my choice” • Client remembers choice (client side) • Uses remember choices on subsequent occasions • Can client generalize to “similar” data resources?

17. Mini critique • Some shortcomings of straw man • Monolithic registry resource • Does not scale to large numbers of rules, frequent edits, or edits by less trusted administrators • Inability to select presentation based on anything buried inside representation of resource • Cannot choose a provider based on a requirements resource containing elements in a particular XML namespace • Inability to select presentation based on project/process • Cannot choose a provider only for resources in a particular project/process • Potential challenge if we want to allow a customer to dictate a preferred presentation within a particular project/process

18. Also considered • HTTP content negotiation (Accept headers) • Only covers alternative representations of data resource • Cannot handle case where client must launch desktop tool • Consult provider (or proxy) to help determine selection rule applicability • Each discovery request requires O(n) roundtrips where n is # of providers • Effort increases as # providers increases • Not scalable • Consult provider (or proxy) to help compute URL tranformation function • Each discovery request requires O(k) roundtrips where k is # of applicable providers • Effort increases as # applicable providers increases • Not scalable