[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Next XML.org Face to Face
Among other things we could be working on in email are the items labelled "normative" in the attached file (I can't get into the OASIS Regrep committee page to provide a URL). Indeed, we SHOULD be working on these in email so that we can reduce the amount of work to be done at face-to-faces, and prepare for the work that is to be done then. In particular, we have no intellectual property policy agreed for contributions to the repository. What is the state of that discussion? best regards, Terry
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html> <head> <title>Policy Considerations for OASIS Registry and Repository</title> <meta name="generator" content="DocBook XSL Stylesheets V0.17"> </head> <body> <h1 > <a name="N236">Policy Considerations for OASIS Registry and Repository</a> </h1> <p><a href="index.html">Back to OASIS Member's-Only Registry and Repository Technical Committee Home Page</a></p> <h3>Revision History</h3> <dl> <dt>Revision 0.2 , 16 August 1999 , TA </dt> <dd>Broken out from draft tech spec, added some points made in Montreal. </dd> </dl> <dl> <dt>Revision 0.3 , 27 September 1999 , TA </dt> <dd>Fleshed out some points with suggestions from Dave Burdett, Commerce One. </dd> </dl> <hr> <p> <b>Table of Contents</b> </p> <dl> <dt> <a href="#busrelations">1. Setting up Business Relations</a> </dt> <dt> <a href="#ipnotices">2. Intellectual Property Notices (normative)</a> </dt> <dt> <a href="#integrity">3. Integrity (normative)</a> </dt> <dt> <a href="#security">4. Security</a> </dt> <dt> <a href="#disaster">5. Disaster Recovery</a> </dt> <dt> <a href="#persistence">6. Persistence (normative)</a> </dt> <dt> <a href="#retraction">7. Retraction</a> </dt> <dt> <a href="#privacy">8. Privacy (normative)</a> </dt> <dt> <a href="#quality">9. Quality Control</a> </dt> <dt> <a href="#conformance">10. Conformance</a> </dt> <dt> <a href="#payment">11. Payment</a> </dt> <dt> <a href="#acl">12. Access Control</a> </dt> <dt> <a href="#migration">13. Format Migration of Registry Documents</a> </dt> <dt> <a href="#addvalue">14. Added Value</a> </dt> <dt> <a href="#preferences">15. User Preferences Among Registries and Repositories</a> </dt> <dt> <a href="#limit">16. Limitation of Legal Liability</a> </dt> <dt> <a href="#qos">17. Notice of Quality of Service</a> </dt> </dl> <h2 > <a name="busrelations"><b>1. Setting up Business Relations</b></a> </h2> <p>Business relations between the Submitting Organization, the Registration Authority, and the Repository Operator are potentially complex–too complex to specify here–and should be established out of band. Issues include ownership of intellectual property rights for entities in the repository, and for the registry's interface to them. </p> <h2 > <a name="ipnotices"><b>2. Intellectual Property Notices (normative)</b></a> </h2> <p>The registry and repository shall have published policies relating to their provision of intellectual property notices for entities in the repository; that is, whether the interface to the registry or repository warns of the existence of copyright notices, asserted licenses, or other intellectual property restrictions or encumbrances, or leaves it to the user to discover them. </p> <h2 > <a name="integrity"><b>3. Integrity (normative)</b></a> </h2> <p>The registry and repository shall have published policies relating to their use of methods to guarantee the integrity of entities in repository and metadata in the registry; for example, does the repository employ digital signatures to ensure against corruption? if transformations of registered entities are served are they signed as well? </p> <h2 > <a name="security"><b>4. Security</b></a> </h2> <p>Security of some sort is required for all functions of the registry and repository, and so should not be considered separately. Security should be sufficient to engender confidence in the registry and repository. </p> <h2 > <a name="disaster"><b>5. Disaster Recovery</b></a> </h2> <p>The complete content of both the registry and repository should be backed up offsite, and the backup tested. Some plan should be made for reconstituting the registry and repository from the backup should the original site be rendered inoperable. </p> <h2 > <a name="persistence"><b>6. Persistence (normative)</b></a> </h2> <p>The registry and repository shall have published policies relating to its plans for continuing in operation and the outcomes to be expected should it cease operation or should business relationships with the owners of its content change. A point of departure for describing archival longevity is the “Reference Model for an Open Archival Information System” (OAIS) which is a draft ISO standard. </p> <p>It should be possible for an SO to request that an entity be kept available for a given length of time, also that it be withdrawn after a given length of time. <b>TO DO:</b> devise the semantics for this, perhaps in a DTD fragment. </p> <h2 > <a name="retraction"><b>7. Retraction</b></a> </h2> <p>It may be desireable to allow an SO to request the retraction of an entity deposited in error. </p> <h2 > <a name="privacy"><b>8. Privacy (normative)</b></a> </h2> <p>The registry and repository shall have published policies relating to the privacy of users and the sale or other distribution of usage information. </p> <h2 > <a name="quality"><b>9. Quality Control</b></a> </h2> <p>ISO/IEC 11179 defines a data element status value, “certified” (Part 6, p. 9) for a “recorded data element [that] has met the quality requirements specified in this and other parts of ISO/IEC 11179.” </p> <p> The registry should provide metadata about what specifications an entity conforms to and who did the testing to determine that conformance. (XML validity vs. well-formedness falls under this heading.) </p> <h2 > <a name="conformance"><b>10. Conformance</b></a> </h2> <p>Conformance requirements (conformance to the Technical Specification will be determined and stated toward the end of the project. </p> <h2 > <a name="payment"><b>11. Payment</b></a> </h2> <p>Some registries or repositories may require payment for use of their services, either in whole or in part—for example, a business might want its entities served by a repository only after payment of a fee, whereas the rest of the repository was available for free. It is possible that payment would be implemented for a repository but not for that repository's registry. </p> <h2 > <a name="acl"><b>12. Access Control</b></a> </h2> <p>Some registries or repositories may control access to their services, either in whole or in part—for example, an organization might ask that a repository make entities available only upon authenticating that the requestor is a member of the organization. It is possible that access control would be implemented for a repository but not for that repository's registry. <b>TO DO:</b> Look at WEBDAV to see how that spec does it. Norbert can provide a DTD for this purpose. </p> <h2 > <a name="migration"><b>13. Format Migration of Registry Documents</b></a> </h2> <p>Inevitably, the format of the registry documents will be revised. Procedures should be established, or at least envisioned, for moving records to a new format, informing SOs of the change, and ensuring seamless transition of services. <b>TO BE DISCUSSED:</b> Such as what? </p> <h2 > <a name="addvalue"><b>14. Added Value</b></a> </h2> <p>Various specifications describe additional, generally domain-specific functionality for registries and repositories, chiefly in the area of searching or automatic processing (the ECO Working Group, the XML/EDI Group). For example, the OASIS-sponsored registry may provide some such added value by cataloguing entities according to their character as XML or SGML entities. Another form of added value is the capability to push content to subscribers. </p> <p>Consequently, the OASIS-sponsored registry and repository should support an API such that value-added services can be built on top of it. </p> <p> (In this section there can be a cumulative wish list of such added value functions if desired.) </p> <h2 > <a name="preferences"><b>15. User Preferences Among Registries and Repositories</b></a> </h2> <p>There must be a means of recording user preferences among registries and, or, repositories, so that a user agent may be instructed to consult them in some particular order. <b>TO DO:</b> Construct a DTD for this information. </p> <h2 > <a name="limit"><b>16. Limitation of Legal Liability</b></a> </h2> <p>It has been suggested that the OASIS-sponsored registry and repository should have a statement of limitation of legal liability (disclaiming responsibility for the use of information in the repository, for example). </p> <h2 > <a name="qos"><b>17. Notice of Quality of Service</b></a> </h2> <p>It has been suggested that the OASIS-sponsored registry and repository should have a statement of the quality of service it can be expected to provide. </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