Re: Zeus: Re: Binding: Master Plan

[Spencer A Marks <smarks@xxxxxxxxxxxxxxxxx>]

 "Brett McLaughlin" <brett@xxxxxxxxxxxxxxx> writes:
> > >
> > > As for Bindings, I see two core classes:
> > >
> > > Objects, and Properties. However, I don't want to call anything
> > an object.
> > > And there is clearly confusion over why a property would not be
> > an object.
> > > So instead, I prefer:
> > >
> > > Containers and Properties. These would both derive from Binding, and the
> > > former is of course capable of "containing" things, while the
> > latter is a
> > > member of something. In addition, you have further breakdown: an
> > > AtomicProperty would be a simple name/value/type deal. However, a
> > > ContainerProperty would be a property of another Container, yet
> > also could
> > > contain things itself (this is essentially an Object, like a
> > List). So I see
> > > this hierarchy in our Bindings:
> > >
> > >                 Binding
> > >                 /     \
> > >                /       \
> > >        Container      Property
> > >             \          /     \
> > >              \        /       \
> > >        ContainerProperty     AtomicProperty
> > >
> > > I can't quite come up with a Container derivation that isn't a Property,
> > > though. Of course, the base Container could be a top level
> > object. So you
> > > might have:
> > >
> > >   Container
> > >     |
> > >     |- AtomicProperty
> > >     |
> > >     |- AtomicProperty
> > >     |
> > >     |- ContainerProperty
> > >          |
> > >          |- AtomicProperty
> > >          |
> > >          |- ContainerProperty
> > >
> > > (And so on)
> > >
> > > Make sense? That, as simple as it is, really represents the
> > types you end up
> > > with in Java.
> >
> > I am probably being dense here, but isn't this just another tree
> > structure? We'd be mapping the XML DOM (tree) to this one? What
> > am I missing?
> 
> First, we won't be using DOM, but JDOM, as it's lighter weight.

Right, I didn't mean to imply we'd use DOM, but mean Document Object
Module in the general. I figured JDOM would be used. 


> Second, a
> tree of constraints will not map directly, or even easily, to a Java object.
> For example, consider that this:
> 
> complexType
>  |
>  |
>  |-- element
>  |
>  |-- attribute
>  |
>  |-- complexType
>       |
>       |-- attribute
>       |
>       |-- attribute
> 
> Actually might map to this in Java:
> 
> public class Foo {
>     List list;
>     String name;
>     Bar bar;
> }
> 
> public class Bar {
>     int number;
>     float anotherNumber;
> }
> 
> The tree of objects is significantly different from the tree of
> constraints.

But the heart of the matter is walking an XML schema, or DTD or what
have you and creating a "Java friendly" tree structured based on the
constraints specified in that document. Is this the gist of it:

   It is not a one to one (or one to many) mapping from the XML tree
   to a java friendly objects, rather is new tree based on contraints defined
   in the XML tree and not its' actual layout. 

> So I want a tree of bindings that accurately represents the Java object
> tree, and that's quite a bit different from the schema one. Make some more
> sense? Also, it provides the required middle layer of representation that
> any format (DTDs, XML Schema, etc) can be converted to. It also won't have
> all of the sym-link style things like rel="foo" that schemas can have, so
> its much easier to translate to Java.
> 
> >
> > I haven't heard of TRAX, can you supply a pointer?
> 
> http://java.sun.com/aboutJava/communityprocess/review/jsr063/jaxp-pd2.pdf

I haven't looked at this yet, but I suspect I can handle this part at
least. 

I will look now. 


Spencer

-----------------------------------------------------------------------------
To unsubscribe from this mailing list, send email to majordomo@xxxxxxxxxxx
with the text "unsubscribe zeus" in the body of the email.
If you have other questions regarding this mailing list, send email to
the list admin at owner-zeus@xxxxxxxxxxxx