RE: Zeus: Re: Binding: Master Plan

["Brett McLaughlin" <brett@xxxxxxxxxxxxxxx>]

> -----Original Message-----
> From: owner-Zeus@xxxxxxxxxxx [mailto:owner-Zeus@xxxxxxxxxxx]On Behalf Of
> Spencer A Marks
> Sent: Tuesday, January 16, 2001 12:10 PM
> To: Binding@xxxxxxxxxxx
> Subject: Zeus: Re: Binding: Master Plan
>
>
>
>
> Hi,
>
> I like the decoupling of the binding from the generator. I see the
> big advantage in not having to tweak the generator once a solid
> binding interface has been defined. Also, having the flexibility of
> multiple input formats is useful too. I definitely wouldn't worry
> about any performance issues that might be incurred as part of this
> abstraction.

Cool. Those were my thoughts, exactly.

>
> I have a couple more comments/questions below
>
>
> "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. 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.
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.

>
>
>
> > This will take in a binding, and then output the resultant classes to a
> > Result. The reason that it doesn't take a Binder is that it is
> possible that
> > we may want to provide transformations of Bindings. This is the JSR-31
> > full-blown version where there is a "binding schema" that
> specifies mappings
> > from the constraints to class generation. For example, a Foo in the
> > constraints may actually become a Bar in Java. We aren't going
> to add this
> > into the first version, but this framework easily allows for
> it, as I see
> > it. So we'll provide an initial SimpleGenerator, that probably
> provides (as
> > convenience):
>
> I am little confused here, but I should read JSR-31 more thoroughly before
> asking for clarification.

Yeah, it's off a bit anyways, so no biggie at this point.

>
> >
> > public void generate(Binder binder, Result result) {
> >   generate(binder.getBinding(), result);
> > }
> >
> > More complex Generator impls can come later.
> >
> > [Side Note: Result abstracts an output. We will provide a concrete
> > StreamResult, and we will also have Source for input, and provide
> > StreamSource. If these ring a bell, they are from the TRAX
> concept, which I
> > think is a good idea]
>
> I haven't heard of TRAX, can you supply a pointer?

http://java.sun.com/aboutJava/communityprocess/review/jsr063/jaxp-pd2.pdf

-Brett

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

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