[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