OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Newbie question: XML design for configuration file

[Erin O'Neill]

Are you really asking if you should use a namespace?  I don't see any other
difference between your two versions.  I'd get squared away on the rest of
your structures first, then see if you need to protect against possible
ambiguity by using a namespace.  That might also depend on whether you might
merge several of these files in the future.

It seems like this might be a good place to use attributes:

 <section name="global">
 <conf key="logDir" value='/var/logs'/>
 <conf key="notify" value='eon@kp.org'/>

This way would probably make it easier to build your Hashmap.  But this also
depends on whether you might need more structure in your fields; if so,
you'd want to stick with elements.

In fact, you might want to see if you could take more advantage of XML's
ability to delineate structure.  Maybe there are dependencies that are
waiting to be captured in the configuration data.

Here's a portion of a tools configuration file from my XML Cooktop

 <XSLT  name="MSXML"
   http-support="yes" />

 <XSLT  name="MSXSL (external)"
   exec="%CONFIG%\xslt\msxsl &#34;!xml!&#34; &#34;!xsl!&#34; -v -t -o
&#34;!res!&#34; !params! "

And here's some mode-specific editing configuration fragments from my JEdit

  <PROPERTY NAME="commentStart" VALUE="&lt;!--" />
  <PROPERTY NAME="commentEnd" VALUE="--&gt;" />
  <!-- WHITE SPACE ( SPACE, TAB ) -->

  <!-- JavaScript -->


Tom P

> Hi all!
> I'm a newbie to XML (and java, tho I have more java experience &
training).  Currently we have an app that needs extensive & complex
configuration.  It seems logical to put the configuration into several xml
docs.  There is no one inhouse with xml experience but the experienced java
programmer seems to think I should "Super" generalize the xml doc.
> The configurations will ultimately endup in a HashMap containing a string
key & a value that can be either a string, hashtable, arrayList, etc.  He
thinks I should basically do something like this:
> ...
> <section name="global">
> <conf key="logDir">/var/logs</conf>
> <conf key="notify">eon@kp.org</conf>
> </section>
> <section name="server">
> <conf key="RunAsDaemon">0</conf>
> <conf key="username">eon</conf>
> </section>
> <section name="Fields" type="hashtable">
> <conf key="fullName">A1</conf>
> <conf key="SSN">A5</conf>
> <conf key="Dept">HR</conf>
> </section>
> <section name="Auth" type="ArrayList">
> <conf key="SSN"/>
> <conf key="employeeNumber"/>
> <conf key="fullName"/>
> </section>
> ...
> something like that. The DTD would be fairly easy to write & a Schema
could be written to set up data restrictions.
> However, in the Java & XML book & the tutorials I've taken, it seems to
me, that this might be too general of an XML design (it does parse as a well
formed XML document). So I'm confused as to how to design the documentation.
It's primary use if for a Java Class but we could add some HTML tags & then
have a java class turn it into HTML documentation (wow 2 uses for one doc!).
> Should I instead make if more specific?? with something like:
> ...
> <myXML:section name="global">
> <myXML:notify>eon@kp.org</myXML:notify>
> <myXML:logDir>/var/logs</myXML:logDir>
> </myXML:section>
> <myXML:section name="server">
> <myXML:RunAsDaemon>0</myXML:RunAsDeamon>
> <myXML:username>eon</myXML:username>
> </myXML:section>
> <myXML:section name="Fields" type="hashtable">
> <myXML:fullName>A1</myXML:fullName>
> <myXML:SSN>A5</myXML:SSN>
> <myXML:Dept>HR</myXML:Dept>
> </section>
> <section name="Auth" type="ArrayList">
> <myXML:SSN/>
> <myXML:employeeNumber/>
> <myXML:fullName/>
> </section>
> ...
> It does seem like the more general is more java like & the more specific
seems more HTML like.  I'm confused!
> thanks in advance.
> erin
> ------------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>
> The list archives are at http://lists.xml.org/archives/xml-dev/
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: xml-dev-request@lists.xml.org