[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: XML class descriptor
- To: ozone-users@ozone-db.org
- Subject: Re: XML class descriptor
- From: Falko Braeutigam <falko@softwarebuero.de>
- Date: Fri, 17 Mar 2000 12:16:03 +0100
- In-Reply-To: <38B53794.C4471B87@sas.upenn.edu>
- Organization: SMB
- References: <200002222024.PAA16331@mail2.sas.upenn.edu> <00022411563900.00660@sheepy> <38B53794.C4471B87@sas.upenn.edu>
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