OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Regrep revised scenarios


Here's the revised scenarios document, extracted from its
earlier context.  Reviewing the definition of "scenario"
I find it means just what the people who think that "use
cases" are paths through scenarios think "use cases" are.

So I didn't change the title.  But whoever wants to take
editorial responsibility is welcome to.

regards, Terry

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">

<html>
<head>
<title>OASIS Registry and Repository
Scenarios</title>
<meta name="generator" content="DocBook XSL Stylesheets V1.11">
</head>
<body>


<h1 >
<a name="N236">OASIS Registry and Repository
Scenarios</a>
</h1>
<p><a href="index.html">Back to OASIS Member's-Only Registry
and Repository Technical Committee Home Page</a></p>
<hr>


<p>
<b>Table of Contents</b>
</p>
<dl>
<dt>1. <a href="#scenarios">Scenarios</a>
</dt>
<dd>
<dl>
<dt>1.1. <a href="#obdtd">Obtaining a DTD Automatically</a>
</dt>
<dt>1.2. <a href="#depentity">Depositing an 
XML-Related Entity</a>
</dt>
<dt>1.3. <a href="#regentity">Registering a
Resource without Deposit</a>
</dt>
<dt>1.4. <a href="#browse">Browsing or 
Searching for a DTD</a>
</dt>
</dl>
</dd>
</dl>


<h2  >
<a name="scenarios"><b>1. Scenarios</b></a>
</h2>
<p>
These scenarios (or use cases, if you believe that use cases
aren't scenarios) involve both users retrieving something
from the repository and contributors registering something
in the registry, which may involve depositing something in
the repository.  
The OASIS Registry and Repository Technical Committee does not intend to specify solutions to all of 
thees scenarios, especially those that involve services built
on top of registries.
The OASIS Registry and Repository Technical Committee intends to add scenarios to this list
only when they affect the data model proposed for the
registry and repository.
</p>

<h3 >
<a name="obdtd"><b>1.1. Obtaining a DTD Automatically</b></a>
</h3>
<p>
A user or user agent retrieves an XML-related entity 
such as a DTD automatically over the Web, as a result of some
use of it in an XML context.  
</p>
<p>
<b>Motivation.</b>
Unless everything needed for parsing
and displaying a document under all circumstances 
is packaged with the
document itself, the document must refer to something (DTD, style sheet,
public text) by identifier.  It is necessary to be able to
retrieve the referred-to entity, and in the Web context,
it is preferrable to be able to do this automatically.
</p>
<p>
<b>Example A.</b>
A user is sent a document the DOCTYPE 
declaration of which refers to a DTD by unique identifier 
(URN, PI, or FPI).  His parser tells him it can't find the 
DTD, so he goes out and retrieves it manually from a repository
(he doesn't need the registry interface because he has a
unique ID but he does need to know where to find the repository).
</p>
<p>
<b>Example B.</b>
A user clicks on a link to the stockmarket
news and his browser receives an XML document the DOCTYPE
declaration of which refers to a DTD by unique identifier;
his browser, which has no copy locally, 
retrieves it automatically from the repository.
</p>


<h3 >
<a name="depentity"><b>1.2. Depositing an 
XML-Related Entity</b></a>
</h3>
<p>
A creator of a resource deposits it, possibly
along with related data, for service
to the public, at some range of accessibility from archival
(retrieval rate could be slow) to utility (retrieval rate
must be fast, large number of connections must be supported,
round-the-clock uptime with failover, etc.).   
</p>
<p>
<b>Motivation.</b>
Many creators of resources lack the facilities
to serve them reliably; even those that can do so may not wish
to deal with the burden.
</p>
<p>
<b>Example A.</b>
An IETF working group decides that a DTD that is
part of their specification, but which the IETF has no facilities
to serve, must be available from a public Web server with high 
bandwidth, and doesn't want to have to maintain the server.  It
sends the DTD to a registry and repository services,
which serves it, 
as in the first scenario.
</p>
<p>
<b>Example B.</b>
A nonprofit publisher wishes its resources to 
be available for inspection and display.  It deposits the resources
in a repository and provides appropriate metadata for the
repository's registry.  The owner of the repository 
undertakes to make them available (but not with a 
high guaranteed quality of service).
</p>
<p>
<b>Example C.</b>
Rosetta Net, a (real life) consortium of hardware 
vendors and suppliers, develops UML models,
DTDs, and sets of text values used in 
their content, all expected to be in heavy demand, the text values
to change frequently.  It deposits the UML models, 
DTDs, and the initial set of 
text values in a repository, contracts for a regular update schedule
and the highest available quality of service, and the repository 
undertakes to serve
them, update them as agreed, push updates to subscribers, and maintain 
high quality of service for retrieval requests.  Rosetta Net 
doesn't need a registry 
interface for this purpose because everything is to happen automatically, 
but it provides appropriate registry metadata so that the DTDs can be
browsed and searched.
</p>
<p>
<b>Example D.</b>
The Air Transport Association, which maintains important
DTDs but make them available only to its members, wishes to 
offload the work of supplying those DTDs.
It deposits the DTDs in a repository, contracts for service
as in Example C, and in addition arranges that the DTDs are
listed in the registry interface but are available only
when an appropriate credential is presented in connection 
with a request for them.  (This is an application of
access control.)
</p>


<h3 >
<a name="regentity"><b>1.3. Registering a
Resource without Deposit</b></a>
</h3>
<p>The owner of a resource, or another repository,
registers the resource in the registry, but does
not deposit the resource itself.
</p>
<p>
<b>Motivation.</b>
Registries can interoperate to increase useability, but the
actual storage location of a resource alone must not restrict
the content of a registry.
</p>
<p>
<b>Example A.</b>
A special-purpose registry wishes to makes its content visible
in another registry, while maintaining that content
in its own repository.
It submits appropriate registry documents to the registry,
including a pointer to its repository,
and agrees with the registry that it will
supply timely update information and that the  registry
will update its records and interface in a timely manner.
</p>


<h3 >
<a name="browse"><b>1.4. Browsing or 
Searching for a DTD</b></a>
</h3>
<p>
A user ready to compose an XML document searches for a
DTD that covers the subject of the document.  
</p>
<p>
<b>Motivation.</b>
Every day in newsgroups and e-mail discussion lists
such as <tt>comp.text.sgml</tt>,
<tt>comp.text.xml</tt>, and
<tt>xml-dev</tt>
people ask whether there is a DTD for some subject area
or functional purpose.  The number of such queries will grow if
XML is widely adopted.  Somehow they have to be answered if wheel
reinvention is to be minimized.
</p>
<p>
<b>Example A.</b>
A user is about to write his resume, and wants
to use XML.  He goes to a registry and looks
in a subject hierarchy (or taxonomy) to find a resume DTD
(this is browsing, not searching).  
The subject hierarchy interface displays three 
appropriate listings, 
he chooses among them on the 
basis of their descriptions, downloads the DTD he chose from the
repository, manually adds it to his SO catalog, and sets to work 
with vi and SP.
</p>
<p>
<b>Example B.</b>
A user is about to write his resume, and wants
to use XML.  He goes to a registry and uses
its search engine to find a resume DTD (this is searching,
not browsing).  The search interface returns
three hits, he chooses among them on the basis of their descriptions,
downloads from the repository the DTD he chose, and loads it into 
his XML writing tool.  The interface also provides a 
time-to-live value, showing him how long he can expect
his resume DTD to be served by the repository.
</p>
<p>
<b>Example C.</b>
A homeowner is about to advertise his house
for sale, and opens his verboprocessor.  He says "take a memo:
real estate for sale" and the verboprocessor automatically contacts
a registry to find an appropriate XML DTD for the homeowner's
jurisdiction. 
He dictates the text of
his ad, and the verboprocessor
sends it to all real estate listing services it can locate.
(In this scenario the verboprocessor uses a registry to find
something in a repository and queries the repository with more
than one query parameter.)
</p>
<p>
<b>Example D.</b>
An XML application designer
needs a component to represent
the list of names of French provinces, so he
consults a registry.  The registry interface
indicates that the list is available as a tab-delimited list
in ASCII, as an XML schema
datatype declaration, and as a parameter entity declaration in
DTD syntax.  He chooses the parameter entity declaration format
by clicking something in the interface, and the 
repository returns it.  
</p>
<p> </p>



<p><a href="index.html">Back to OASIS Member's-Only Registry
and Repository Technical Committee Home Page</a></p>
</body>
</html>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC