RE: building an object model of a XML schema

[Jeff Lowery <jlowery@scenicsoft.com>]

> 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.

I think I can say: "put this type's child elements in a dictionary, with
look up on X" and let the language-specific implementation do with it as it
will. The implementation will have the associated interface, even though the
<gasp> newly-proposed schema would not specify one. It only indicates
behavior it deems useful to consumers of the type data, but only in a
hint-like fashion, not explicitly. It's up to code generating utilities to
figure out what the proper mapping to a concrete language would be,
interface to be determined at that point.

> Two classes could easily have the same attributes and yet be 
> so incompatible
> that one could not even be cast to the other.  

Possibly, yes; but for well-understood "archetypes" I'm not sure that's
obviously true. Even if it were true, I'm not sure that it matters: the data
is the interface. We're only trying to help with performance optimization of
consuming apps by giving them hints as to how data should be stored and how
it should be accessed, but in an inspecific manner. I would expect
applications to share data via XML (fer instance), not through some defined
API in the neo-schema that would result in common APIs in all generated code
(which would be a problem in any case because of language
incompatibilities).

> 
> If you consider a class to have two parts - the data part and the
> interface - you could match types as specified by xml-schema 
> to the data
> part, and you could have code that automatically creates such 
> data-only
> classes and fills the fields form an xml document.  But xml-schema has
> nothing directly to say about their behavior.

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.

> 
> So are you thinking of data-only classes, or what? 

No, not data-only. Interface for simple accessor/mutators can be inferred
with the proper naming convention. Castor or JAXB would serve as a
reference. The archetypes (I keep expecting someone to object to the name)
that specify "hash map" or "dictionary" would not imply interface, but
instead suggest useful behavior.

> And when you say
> "removing the XML-ness from XML Schema", do you mean express 
> the same things
> but in a non-xml language, or do you mean to use an xml 
> language but not to
> express parts of the xml infoset?

The latter, yes. I think XML is sufficiently expressive for my intents. Not
to mention that I have to stay on topic or risk getting cast out from the
mailing list.

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. 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.

Now, a modeling tool such as UML might have such capability, but if it's
easy enough to do, I would prefer decorating the data model by hand where
possible, and have the modeling tool come later. Kinda like what happened
with XML Schema.

These are very nascient ideas and people are referring me to articles that
give some indication that something along these lines are in the works by
academicians, which is good. In the meantime, real-world solutions are being
developed that specifically address XML to Java mapping. These may
ultimately work fine for that domain, and perhaps pioneer the way towards
broader solutions. It may be best to wait and see what develops.