© 2008 IBM Corporation Presenting Data Resources Last updated Nov. 14, 2008

© 2008 IBM Corporation

Presenting Data Resources

Last updated Nov. 14, 2008

© 2008 IBM Corporation2

Note: This is complete rework of proposal entitled Presentation URLs from Resource URLs (Sep. 22, 2008)


The Problem

• Most data resource will have XML-based representations

• These representations are not directly presentable to users

• Interaction with data resources requires client agent that understands data resource format and can present it in proper context

• What are mechanisms that permit data resources to be presented to users?

• What are mechanisms that permit user to navigate hyperdata links between data resources?


Complicating factors

• Open-ended set of types of data resources– Unlimited– Even if all XML-based, lots of different schemas

• Custom data resource types– Resource types and their presentations need not be universal– E.g., customer-defined data resource types

• Hyperdata links could reference data resources anywhere on web– On same JTS – Off-world

• On different JTS• On non-JTS server

• Modular clients– Client agents written with knowledge of only certain types of data resources

• Open-ended set of styles of presentations– Desktop applications– Web UIs– Composable widgets– …


Complicating factors

• Hyperdata links from R to S– From representation of data resource R– To URL of data resource S

• Client agent authorized to access R might not be authorized to access S– S might live on different server from R

• Client agent that understands R might not be able to understand S representation – S might have data type arbitrarily different from R

• Client agent that presents R might not be able to present S – S might require different client agent to present than R


Desideratum

• Desideratum: Client agent presenting data resource R containing hyperdata link to data resource S should be able to determine client agent for S without retrieving S

• Avoids key issues– Security issues with accessing S– Source client agent not able to understand schema for S representation

• Familiar examples of systems with this characteristic– Desktop apps – file type registry– How web browser handle media types


System

How desktop apps do it(for Open As… cases)

X presenting R representation 1. X consults System for registry info2. X chooses client agent Y based on type S – with possible user input3. X hands over control to Y passing S4. Y retrieves SY presents S representationMeets desideratum – client agent X does it without retrieving S

Sourceclient

agent X

Targetclient

agent Y

R S

1

2

4

Registry

3

System = desktop OSClient agent = desktop app


How web browsers do it

X presenting R representation

1. X hands over control to System passing S

2. System retrieves S to discover its type

3. System consults registry and chooses client agent Y based on type S

4. System hands over control to Y passing S representation

Y presents S representation

Meets desideratum – client agent X does it without retrieving S

Sourceclient

agent X

Targetclient

agent Y

System

R S

Registry

1

2

3

4

System = browserClient agent = browser plug-in


Approaches

• In our world client agent could be– Desktop application; e.g., DOORS client, RTC client, RRC client, …– Webtop application; e.g., RQM web UI, RTC web UI, …– Wigdet/viewlet; e.g., as in Telelogic Webtop, Jazz Web Dashboards– Web browser plug-in; e.g., Acrobat Reader, QuickTime– … (e.g., synopsis/hover help)

• Key design question: Does client agent X knows which client agent Y to use to present S?

• YES – Direct approach– Client agent X knows to use client agent Y to present S

• NO – Discovery-based approach– Client agent X must discover client agent Y to use to present S


Preliminaries

• 2 handy techniques that proposal will use

1. URLs for launching webtop and desktop presentations

2. Embellishing references with information about referent


Technique: URLs for launching webtop and desktop presentations

• URLs provide uniform mechanism for launching desktop and webtop apps– Used extensively in Telelogic CIA

• Use standard HTTP scheme for webtop app presentations• Example URLs for webtop app presentations of http://eg.com/r1

– http://eg.com/present-requirement-r1.html– http://eg.com/show-requirement?url=http://eg.com/r1– http://webui.eg.com/requirements/eg.com/r1– http://webui.eg.com/u1656727243

• Use non-standard schemes for desktop app presentations– A la “mailto”– Register URL handler with desktop OS when tool installed

• Example URLs for desktop app presentations of http://eg.com/r1– doors:eg.com/r1– rrc:?url=//eg.com/r1

• Alternative to non-standard schemes– Run local server on desktop who’s job is to launch desktop apps– http://localhost:1555/applaunch?tool=doors,url=http://eg.com/r1


Technique: Embellishing references with information about referent

• Example: Atom links

• <atom:link href="http://www.blogger.com/feeds/2956442/posts/default/8938437484" rel=“edit" title=“The GUI world is a mess" type="application/atom+xml;type=entry"/>

• “title” attribute (optional) – displayable string – for presenting link to user• “type” attribute (optional) – advisory media type – hint about target resource

• Slight de-normalization of data– A bit of info about target resource is duplicated at each site of reference– Tradeoff

• Up front hint available on the cheap• Onus on party creating link to supply duplicate info• Duplicated info could become stale

– Common in web world where deferencing a URL entails real work



Approaches

1. Direct approach

2. Discovery-based approach


Direct approach

• Inspired by how blogs and Atom feeds work– Summary of investigation on separate slide deck [TBD – add hyperlink]

• Embellish hyperdata links with presentation URL

• <xyz:someKindaLink href="http://eg.com/r1" title=“Requirement 1" type=“application/oslcrequirement+xml" present="http://eg.com/present-requirement-r1.html" />

• “present” attribute (optional) – advisory client agent/home presentation URL– For opening home presentation in appropriate client agent

• Allows source client agent to DIRECTLY launch appropriate target client agent on target resource


Direct approach

X presenting R representation – user requests navigation to S

1. X hands over control to client agent Y (link “present” attr) passing S

2. Y dereferences S



Sourceclient

agent X

Targetclient

agent Y

R S

21

Client agent = {desktop app, webtop app}


Discovery-based approach

• Inspired by desktop OS file type registry

• JTS-based registry associating media types and client agents

• Embellish hyperdata links with advisory media type

• <xyz:someKindaLink href="http://eg.com/r1" title=“Requirement 1" type=“application/oslcrequirement+xml" present="http://eg.com/present-requirement-r1.html" />

• “type” attribute (optional) – advisory media type– For pre-selecting client agent/presentation based on expected media type

• Allows source client agent to DISCOVER and launch appropriate target client agent on target resource using information in registry


System

Discovery-basedapproach

X presenting R representation – user requests navigation to S

1. X asks System for registry

2. X uses registry to- determine available client agents based on media type of S (link “type” attr) – with possible user input- choose chooses target client agent Y – possibly with user input- compute presentation URL for S and Y

3. X hands over control to Y passing S

4. Y dereferences S



Sourceclient

agent X

Targetclient

agent Y

RS

1

2

4

Registry

3

System = Jazz Team ServerClient agent = {desktop app, webtop app}


Rule base

• Rule base is a set of selection rules

Presentation type

Provider label

Provider ID

Media type pattern URL transformation function

(input pattern -> output template)

web JFS Web Client

1263 application/oslcuser+xml http://{host}/{path} -> http://jf1/webui/user/{host}/{path}

desktop RTC Client

7483 application/oslcworkitem+xml;tool=rtc http://{host}/{path} -> rtc:{host}/{path}

desktop RTC Client

7483 application/oslcbuild+xml;tool=rtc http://{host}/{path} -> rtc:{host}/{path}

web RTC Web Client

2662 application/oslcworkitem+xml;tool=rtc http://{host}/{path} -> http://{host}/webui/workitems/{path}

web BuildForge Web Client

5242 application/oslcbuild+xml http://{host}/{path} -> http://b1/show-build?//{host}/path}

web RQM Web Client

9177 application/oslctest+xml {url} ->http://rqm1.example.com/test&url={PercentEncode(url)}

desktop DOORS Client

6321 application/oslcrequirement+xml;tool=doors http://{host}/{path}-> doors:{host}/{path}

desktop RRC Client

2233 application/oslcrequirement+xml;tool=rrc http://{host}/{path} -> rrc:{host}/{path}

desktop RRC Client

2233 application/oslcrequirement+xml http://{host}/{path} -> rrc:{host}/{path}


Selection rules

• Selection rule is declarative conditional expression

• Fields– Presentation type: desktop– Provider label: DOORS Client– Provider ID: 6321– Media type pattern: application/oslcrequirement+xml;tool=doors– URL transformation: http://{host}/{path} -> doors:{host}/{path}

– Roughly “The DOORS Client is a desktop application

for presenting data resources with media type application/oslcrequirement+xml;tool=doors

The data resource URL maps to a corresponding presentation URL by …”


Client agent uses rule base to discover presentations

• Client agent uses a rule base to discover available presentations for given data resource

• Inputs– Data resource URL– Expected media type of data resource– List of presentation types of interest (e.g., just web presentations, desktop and web, widget, …)– Rule base

• Client agent determines applicable selection rules by matching entry type and media type pattern– More specific media type pattern trumps less specific

• Provider labels allow choices to be presented to user

• Provider IDs facilitate recording user’s selection for future use

• Client agent applies URL transformation function to map data resource URL to presentation URL


Design Assumption

• Tool-specific tagging of media type– Assuming that tools will tag their resources’ media type with tool ID– E.g., necessary to ensure a requirement created in DOORS repository will be shown with DOORS client

agent


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 transform does not require adding code to server

• Note: Interesting information in data resource URL gets encoded in presentation URL– Should be reversible– Presentation provider should be able to reconstruct data resource URL from presentation URL


Where does rule base come from?

• Jazz Team Server provides global Provider Registry

• Provider Registry is exposed though system-defined resource– Discoverable through other JFS discovery services

• Provider Registry representation is rule base in XML– Subelements for selection rules

• Selection rules – Largely contributed by JTS extensions at their install time– Tweakable by system administrator

• Requires high administrative permissions to update

• Requires low permissions to retrieve

• Provider Registry changes slowly

• Client agent can retrieve once and cache


Limitations of proposed discovery approach

• Limitation of media type pattern matching– Inability to select based on info buried inside representation of resource– Cannot choose a provider based on requirements resource containing elements in a particular XML

namespace– Puts premium on making good use of media types (true of web generally)

• Limitation of global rule base– 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 customer to dictate preferred presentations within a particular

project/process

• Inherent JTS-centricity– Having to ask a JTS means it does not work without a JTS– Potential challenge for world envisioned by OSLC initiative


Also considered

• HTTP content negotiation (Accept headers)– Only covers alternative representations of data resource– Cannot handle case where client must launch desktop app


Direct vs discovery-based approach

• Both approaches have their strengths and weaknesses

• Direct approach+ Custom data types

+/- No opportunity for user input/influence

- Single presentation style

• Discovery-based approach- Custom data types on another server

+ User input can influence choice

+ Multiple and third-party presentations

+ Multiple presentation styles – widgets, etc.

• Neither is better than other for everything


Combining both approaches

• Source client agents should provide user affordances for “Open” and “Open As…” navigations for hyperdata links

• Direct approach for normal “Open” navigation – “present” attribute gives presentation URL– If none, use data resource URL as presentation URL (backstop presentation)– Bonus: Normal web URLs (i.e., ones that are not data resource URLs) work properly

• Discovery-based approach for “Open As…” navigation– “type” attribute gives advisory media type– If none, disable “Open As…”


Additional capabilities

• Add-on capabilities to further enhance story

1. Web-based presentation chooser

2. Presentation selection service

3. Backstop presentations

4. Home presentation links


Add-on: Web-based presentation chooser

• Web-based presentation chooser– Web page that lets user choose desired client agent for given data resource, media type, …– Hosted on a JTS - uses JTS’s Provider Registry– E.g., GET http://jf1.eg.com/chooser?url=http://eg.com/r1

– Typical response would be HTML page offering choices


Add-on: Presentation selection service

• Presentation selection service– Additional web service that asks server to choose client agent for given data resource, media type, …– Encapsulates presentation selection algorithm on the server (a la earlier straw man proposal)

– Hosted on a JTS - uses JTS’s Provider Registry– E.g., GET http://jf1.eg.com/present?url=http://eg.com/r1,type=app/oslcreq+xml

– Typical response would be 3xx redirect to appropriate presentation URL• http://eg.com/present-requirement-r1.html• doors:eg.com/r1• http://eg.com/r1• http://jf1.eg.com/chooser?url=http://eg.com/r1


Add-on: Backstop presentations

• Backstop presentations– XML-based representations of data resources– Should use type-specific XSLT stylesheet to provide backstop webtop presentation– Shows when data resource URL is entered in web browser address bar

Example explained on http://moths.ca/jazz/


Add-on: Home presentation links

• Home presentation links– XML-based representations of data resources– Should carry link to home presentation (when there is such a thing)– Gives backstop presentation (and others) easy way to hyperlink to home presentation

Example explained on http://moths.ca/jazz/


Summary of proposal

• Client agents should use direct approach for normal “Open” navigation

• Facilitated by– Hyperdata links embellished with presentation URL for target data resource

• Client agents should use discovery-based approach for “Open As…” navigation

• Facilitated by– JTS-based global provider registry with selection rules matching on media type– Hyperdata links embellished with media type for target data resource

• Further enhanced by– Web-based presentation chooser– Presentation selection service– Backstop presentations– Home presentation links

Documents

© 2008 IBM Corporation Presenting Data Resources Last updated Nov. 14, 2008