summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authornanbor <nanbor@ae88bc3d-4319-0410-8dbf-d08b4c9d3795>2002-01-14 04:45:46 +0000
committernanbor <nanbor@ae88bc3d-4319-0410-8dbf-d08b4c9d3795>2002-01-14 04:45:46 +0000
commit40c8a0b2601b7617c22bea7c5623ab559e6d29ad (patch)
treec4997cb0666aef659e0421c6ae958b0e1363bb9a
parent376f237f857817de3e78ccb7e1f7349b72124bf4 (diff)
downloadATCD-40c8a0b2601b7617c22bea7c5623ab559e6d29ad.tar.gz
*** empty log message ***
-rw-r--r--ACEXML/examples/test_docs/svcconf.dtd65
1 files changed, 65 insertions, 0 deletions
diff --git a/ACEXML/examples/test_docs/svcconf.dtd b/ACEXML/examples/test_docs/svcconf.dtd
new file mode 100644
index 00000000000..dded178c1f7
--- /dev/null
+++ b/ACEXML/examples/test_docs/svcconf.dtd
@@ -0,0 +1,65 @@
+<!-- $Id$ -->
+<!-- Document Type Definition for XML ACE Service Config files -->
+
+<!-- An ACE_Svc_Conf document contains zero or more entries -->
+<!-- The entries are processed in the order they appear -->
+<!-- in the ACE_Svc_Conf file. -->
+<!ELEMENT ACE_Svc_Conf (dynamic|static|suspend|resume|remove|stream|streamdef)*>
+
+<!-- Streams are separate into two elements. One defines how -->
+<!-- the stream should be constructed and the other defines -->
+<!-- what to do with it. The identity of a stream is defined -->
+<!-- in the first dynamic/static element. -->
+<!ELEMENT streamdef ((dynamic|static),module)>
+<!-- @@ Do we ever need to suspend/resume/remove modules when -->
+<!-- constructing a stream? Should we leave only dynamic -->
+<!-- and static here? -->
+<!ELEMENT module (dynamic|static|suspend|resume|remove)+>
+
+<!-- A 'stream' element controls the stream object -->
+<!-- @@ Likewise, we are reusing the 'module' element here. -->
+<!-- Do we ever need to insert new modules into a stream? -->
+<!-- Nanbor: I guess we can do that. -->
+<!ELEMENT stream (module)>
+<!ATTLIST stream id IDREF #REQUIRED>
+
+<!-- A 'dynamic' entry. -->
+<!-- @@ The kind of attributes the corresponding initializer -->
+<!-- should take seems to be determined by the 'type' -->
+<!-- attribute. Should we further partition the dynamic -->
+<!-- element definition into several elements? E.g. into -->
+<!-- dyn_service_object/dyn_module/dyn_stream? -->
+<!-- Nanbor: Will that be too confusing? -->
+<!ELEMENT dynamic (initializer)>
+<!ATTLIST dynamic id ID #REQUIRED
+ status (active|inactive) "active"
+ type (module|service_object|stream) #REQUIRED>
+
+<!-- Initializing function for dynamic entry. -->
+<!ELEMENT initializer (params)*>
+<!ATTLIST initializer init CDATA #REQUIRED
+ path CDATA #IMPLIED>
+
+<!-- A 'static' entry takes an ID attribute and an optional -->
+<!-- parameter lists. -->
+<!ELEMENT static (params)*>
+<!ATTLIST static id ID #REQUIRED>
+
+<!-- A 'suspend' entry takes an ID attribute. -->
+<!ELEMENT suspend EMPTY>
+<!ATTLIST suspend id IDREF #REQUIRED>
+
+<!-- A 'resume' entry takes an ID attribute. -->
+<!ELEMENT resume EMPTY>
+<!ATTLIST resume id IDREF #REQUIRED>
+
+<!-- A 'remove' entry takes an ID attribute. -->
+<!ELEMENT remove EMPTY>
+<!ATTLIST remove id IDREF #REQUIRED>
+
+<!-- A params entry can appear within dynamic and static. -->
+<!-- Parameters can appear multiple time and the SAX handler -->
+<!-- for Service_Configurator is supposed to concatinate -->
+<!-- them together with appropriate white space to separate -->
+<!-- parameters appeared in separate elements. -->
+<!ELEMENT params (#PCDATA)> \ No newline at end of file