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


Help: OASIS Mailing Lists Help | MarkMail Help



   xml schema -> java code

[ Lists Home | Date Index | Thread Index ]
  • From: rsanford <rsanford@nolimitsystems.com>
  • To: xml-dev@lists.xml.org
  • Date: Wed, 06 Sep 2000 11:54:32 -0500


attached is a perl script and supporting java classes that allow
you to generate java source files to navigate through your DOM
without using the ugly DOM api.

read the long version first and then let me know if you have
questions or comments,


in the past i was using ibm's VisualDTD to edit my dtd/schema. i 
thought it was a decent little app and really appreciated that it
generated java classes for the elements in my dtd so that i could
navigate through the DOM without actually using the incredibly
ugly DOM api. unfortunately the schemas that it produces are not
W3C compliant (as of the latest recomendation since it isn't an
official specification yet) and the xerces parser won't validate
against it.

that meant that i needed to move to a real xml schema (i'm using
XMLSpy as my schema and test document editor) which meant that i
lost the ability to have code automatically generated for me.

all is not lost, however. since i didn't really want to be hand-
coding all that java that i used to have automatically generated
for me i decided to spend a few hours having the code automatically
generated for me. perl to the rescue!

attached is a naive, imo, perl script to read a W3C schema and
generate supporting java classes just like VisualDTD does. i
say the perl code is naive because:
a) i'm new to perl and am certain there is a better way to do
   almost everything i'm doing in my script.
b) the code makes some very naive assumptions about the way
   your schema is laid out. in particular it looks for the
   following constructs:
      <xsd:complexType name="MyMasterType" content="elementOnly">
            <xsd:element name="MySlave" type="MySlaveType"/>
         <xsd:attribute name="Name" type="xsd:string" use="required"/>
         <xsd:attribute name="Weapon" type="xsd:string" use="required"/>

it will generate a class for each complex type, get/set methods
for each attribute, a getElementCount() method if a child
element has unbounded cardinality, a getElementAt(index) method
for iterating through unbounded child elements, and a getElement()
method for retrieving a child method with cardinality of one.

the contained element will not implicitly have a class generated
for it. this rules out a contained element that looks like:
   <xsd:element name="MySlave" type="xsd:string"/>

get/set of attribute values is only using string values at this
point since that is the way the ibm code generated them and i
want to stay compatible for now (my qa manager would be angry
otherwise). i will be expanding it to use actual type information

in the script you will notice the line 
   use XML::Parser;
this means you need to have the xml parser library. you can
find more information about getting the xml parser library at

i have also attached the supporting java classes (originally
by ibm but i have modified them) so you don't have to go and
look for them on ibm's site and then modify them yourself
(although you may want to anyway). you'll need to place them
in the appropriate 

if you have any questions or comments, please let me know,





News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS