[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Regrep 26 May conf call agenda
OASIS Regrep TC Conference Call Friday 21 April 2000 Agenda - discuss agenda, new items - agree on schedule for period before Paris meeting - NIST update (including status of info model) - EBXML update - XML.org update - review previous Design Principles (attached) with a view to affirming them - new items - adjourn call details: Friday 26 May 00 10-11 AM Pacific domestic (12 lines) 888-381-5775 internat'l (1 line) 415-228-4637 pin number: 14272 leader: Terry Allen confirmation number (if needed): 1158333
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html> <head> <title>Design Principles</title> </head> <body> <h2 > <a name="design"><b>2. Design Principles</b></a> </h2> <p>The following design principles have been agreed to: </p> <ol> <li> <p> The Registry Technical Specification shall employ existing standards and specifications where possible, avoiding specifications that are not stable. OASIS must be prepared to track developments such as ANSI X3.285, which is the proposed revision of Part 3 of ISO/IEC 11179, and the W3C's XML Schema specification so that they can be considered for use when they are mature. </p> </li> <li> <p> The normative part of the Registry Technical Specification shall be as small as reasonable. </p> </li> <li> <p> The normative part of the Registry Technical Specification shall be complete enough that registries and repositories conformant to it can interoperate in an extensible and distributed network. </p> </li> <li> <p> The normative part of the Registry Technical Specification shall be extensible; in particular, it shall be possible to extend the registration information schema or DTD without inhibiting interoperability among registries. (This point is called out because the registration information schema or DTD is likely to be a normative part of this specification). </p> </li> <li> <p> Immediate needs should be satisified first. A repository offers opportunities for the application of many kinds of technologies; OASIS should focus on providing DTDs and schemas, and an interface to their metadata, before proceding to other matters. </p> </li> <li> <p>The registry shall be user-friendly. </p> </li> <li> <p>The Registry Technical Specification shall be vendor-neutral. </p> </li> <li> <p>The Registry Technical Specification shall be as easy to implement as practicable. </p> </li> <li> <p>The Registry Technical Specification shall use XML by preference for encoding of information and documents. </p> </li> <li> <p>The first complete and finished version of the Registry Technical Specification shall be delivered quickly. </p> </li> <li> <p>The Registry Technical Specification shall assume the use of HTTP. </p> </li> <li> <p>The registry and repository shall be scaleable. </p> </li> <li> <p>The implementation of the registry and repository shall be testable against their design documents. </p> </li> </ol> </body> </html>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC