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

Re: XML class descriptor



On Thu, 24 Feb 2000, Steve Tinney wrote:
> > 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

Steve, now that I'm about to realy release the XML class descriptor I read back
your mail about the XML specific things of the descriptor. I agree that name
spaces and "enumeration properties" have to be used. But I'm not sure if
castor, the tool we are using for this kind of work, supports this and I don't
want to put to much time in here. I'll put this on Daniel's to-do list (the guy
who actually wrote the castor ozone glue code). The first release of the
simple version might also be a good for discussing things a bit further.


Falko
-- 
______________________________________________________________________
Falko Braeutigam                         mailto:falko@softwarebuero.de
softwarebuero m&b (SMB)                    http://www.softwarebuero.de