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

Re: XML class descriptor



> Ok, I will change the schema to not use attributes. The example would then be
> something like:
> 
> <?xml version="1.0"?>
> <javaobject>
>         <name>button<name/>
>         <package>java.awt</package>
>         <superclass>java.awt.Component</superclass>
>         <constructors>
>                 <xconstructor>
>                         <parameter>java.lang.String<parameter/>
>                 <xconstructor/>
>         </constructors>
>         <methods>
>                 <xmethod>
>                         <name>toString<name/>
>                         <parameter>java.lang.Object<parameter/>
>                         <locklevel>READ<locklevel/>
>                 </xmethod>
>         </methods>
> </javaobject>
> 
> Other ideas?

One question raised before is whether you want to encode, or at least
define the encoding of, information such as static/non-static, scope and
return value.  For this information, attributes on the xmethod element
would be natural as they are all unary and in some cases possessed a
defined range of possible values.

    <xmethod static="y" scope="private" return="void">...

This is a matter of your design goals, of course, not of the nature of
XML.

Incidentally, something to keep clear is that there is a world of
difference between </xmethod> and <xmethod/>.  The former is an end tag,
the latter is an empty tag, equivalent to <xmethod></xmethod>.  The XML
in your example is therefore invalid, but I suspect that this is merely
a matter of typos (or thinkos).

It is difficult to be this disciplined, but I usually try (and usually
fail) to ensure that all XML formats, including interim and internal
ones, have a DTD describing them somewhere.  It's a useful
code-documenting feature for one thing, and can be useful when
debugging, especially when someone else has ditzed with the codebase and
made a seemingly innocent mod to the XML code generator.  Being able to
validate is one of the big wins of XML as a data format.

In this case, as I began to write a DTD for your sample, I realized (a)
that maybe 'class' would be a better name than 'javaobject' (or did you
have a specific reason in mind for not calling it 'class'?) and that one
unaddressed issue is that of inner classes; do you need to represent
them?
Also, are these fragments intended as standalone 'javaobject' documents,
or will they occur in some enclosing context?

One possible DTD, then, would be:

   <!ELEMENT class (name , package? , superclass? , 
                    constructors? , methods? , class*)>
   <!ELEMENT name #PCDATA>
   <!ELEMENT package #PCDATA>
   <!ELEMENT superclass #PCDATA>
   <!ELEMENT constructors (xconstructor*)>
   <!ELEMENT xconstructor (parameter*)>
   <!ELEMENT parameter #PCDATA>
   <!ELEMENT methods (xmethod*)>
   <!ELEMENT xmethod (name , parameter* , locklevel)>
   <!ELEMENT locklevel #PCDATA>

Back on the element or attribute debate, if locklevel has a defined
range of values, you might want to use instead:

   <!ELEMENT locklevel EMPTY>
   <!ATTLIST locklevel (READ|WRITE|RDWR|NONE) "NONE">

or the like.  The same goes for any other property whose range of values
can be expressed as an enumeration.

Depending on what contexts you foresee this stuff being used in, you
might consider using a namespace prefix on the element names, e.g.,
ozone:class instead of just class.  This would make it easy to include
the class descriptions in other documents without concern over name
clashes; that may not be of importance to you, though.  If you do go the
namespace route, you will need to include either directly on the
container or in the DTD a namespace declaration:

    <ozone:class xmlns:ozone="http://ozone-db.org/namespace">

You don't need it on child elements, and if you are using a !DOCTYPE +
DTD, you can also put the xmlns in the DTD:

 <!ATTLIST ozone:class 
     xmlns:ozone CDATA #FIXED 'http://ozone-db.org/namespace'>

 Steve