Re: building an object model of a XML schema

[Paul Cody Johnston <pcj@inxar.org>]

* Jeff Lowery (jlowery@scenicsoft.com) wrote:
> > I'm going to go out on a limb here (except I'm in good 
> > company) and claim
> > that if there is no interface, there IS NO type so far as O-O 
> > is concerned.
> 
> What about primitive datatypes? Are they not types? I'm not sure how you
> would classify C struct-like classes in C++ (struct is a class in C++,
> remember). But I get your drift.
> 

Primitive datatypes are definitely types, and they have an interface.
The interface in Java for an int is that you can access one, do
arithmetic on them, and cast them to other primitive datatype.  But
the interface is built into the compiler (and runtime).

> 
> I think a class has three parts, data, interface, and implementation. It's
> the implentation I seek  to address. Performance, for example, is not
> expressed in data or in the interface, although if I was calling push() and
> pop() I might think I was using a stack, but it could be deque.
> 

<snip>

> 
> The sword that this whole concept is likely to fall on is whether or not a
> fairly simple set of behavioral archetypes is sufficient for tweaking
> generated classes so that data is dealt with efficiently. 

This statement needs an example.  How does a behavioral archetype get
used to by some processor / generator?

Another issue
> occurs to me too, and that is the adjustment of data "graininess" from the
> application standpoint. For example, if I have:
> 
> 	<point unit="mm">
> 		<x>23.3</x>
> 		<y>42.0</y>
> 	</point>
> 
> I probably don't want to generate a class such as:
> 
> class Point
> {
> 	String m_unit;
> 	double m_x;
> 	double m_y;
> 
> 	double getX();
> 	double getY();
> 	String getUnit();
> 	
> 	void setX( double x );
> 	void setY( double y );
> 	void setUnit( String unit );
> };
> 
> I would like to see generated a setPoint(double x, double y, String unit)
> method, also, for convenience. Two ways of doing this: one is to use the
> generated classes as bases for higher-level classes that have convenience
> methods such as the one just mentioned. The other is to somehow tweak the
> data model with additional information to indicate that x, y, and unit
> should have a common set() method in addition to those automatically
> generated.
> 

Just thinking out loud, but this is how I could imagine this being
implemented.

(1) Create a new namespace to be used for prefixing special
    attributes.  These special attributes are used to pass hints to
    the generator tool.

(2) Write a generator tool that looks for those "special" attributes
    in a XML schema (or elsewhere perhaps) to generate interfaces /
    classes based on the schema and hints.

Example namespace: adt (abstract data type)

Potential things you might want to say to the generator:

adt:isType = "true"|"false"

 Should this element be represented as a class (or equivalent)?

adt:typenamePrefix = "My"

 Override prefix class naming

adt:typename = "MyClassName"

 Override class naming altogether

adt:isMember = "true"|"false"

 Should this `thing' be a data member of the generated class(es)?

adt:hasAccessor = "true"|"false"

 Should the `thing' have a get method?

adt:hasMutator = "true"|"false"

 Should the `thing' have a set method?

adt:getMethodPrefix = "xxx"
adt:setMethodPrefix = "yyy"

 To override the default generator set and set prefixes.

atd:getMethodName = "xxx"
adt:setMethodName = "yyy"

 To override the default generator set and set names completely.

Those are obvious ones.  Other things that would take more thought:

adt:mutator "x y"

 Assuming two properties 'x' and 'y', create a method like:

 public void setXY(int x, int y) {
     setX(x); setY(y);
 }

Content models are obviously regular expressions that define what
kinds of things can be seen in a particular sequence.  Often times a
content model is "simple"; it is easy to disassemble the regular
expression at concatentation points.  For example:

 <!ELEMENT customer (name, address, transaction*)>

So this is easy to map to a class having methods like:

 Name setName
 Address setAddress
 List getTransactions
 void addTransaction
 void removeTransaction
 ...

Therefore, you could hint on a XML Schema particle element that the
List type of transactions should be of a particular type:

adt:collection = "list, linked-list, array-list, array"

Anyhow, you get the picture.  At any rate, I would think this
resembles both Castor and JAXB, and any other mapping technology.
This issues that are going to creep in to any effort are:

(1) Generality comes at the price of specificity.  If your tool is
    general, people may not want to use it if a better tool exists in
    the language they're interested in (like Castor and JAXB).  Not
    too many people are sophisticated enough or have the need to
    generate implementations in Java, Perl, Python, C++, Ruby, etc all
    at the same time. Be kinda cool though.

(2) Avoiding specificity is hard.  I tried to minimize exposure to
    Java-only stuff in the above example, with poor effect.

(3) Mapping anything, in general, isn't easy, because you're
    essentially trying to patch together things that have different
    ideas and different requirements.

Ok, enough rambling...

Paul

+---------------+---------------+------------------+
| Paul Johnston | pcj@inxar.org | http://inxar.org |
+---------------+---------------+------------------+