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 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