xml-xmlbeans-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Bau" <david....@bea.com>
Subject Re: Current start-with-java annotations
Date Mon, 24 Nov 2003 22:47:11 GMT
Pcal writes:

> you will notice that there are many cases where he faces exactly the same
> dilemma in several places (e.g. cmp-field and cmr-field), and that he went
> the route of having separate annotation types.
> As I see it, the downsides of this approach are
>    1) as you point out, you may have to introduce some arbitrary rules
> "only one of these annotations must appear."
>    2) you may get some redundancy when annotation types are similar
> However, the upsides are:
>    3) You don't have arbitrary rules like "isNillable can only be
> if isAttribute is true."  With the ejbgen-style annotations, you will
> actually get compile-time checking under 175 for this kind of correctness,
> because these sorts of constraints are expressed in the annotation types
> themselves.
>    4) More readability and clarity about how java constructs are mapping
> into the schema.
> IMHO, #3 outweighs #1, and #2 and #4 are at worst a wash.

Agreed, those are persuasive.  I'm convinced.

The other thing to look out for will be how "toolable" the annotations will
be, i.e., how nicely they can show up in an IDE.  But in the absence of any
examples we probably should assume that in the world of 175, tools will have
to make structure you're proposing work nicely.

> However, I can anticipate one catch with 175, which is that you are only
> able to specify one annotation of a given annotation type for a given java
> construct.  So if we had a separate rootElement annotation type, we would
> only be able to map a class to a single root element.  The way around this
> would be a container type (rootElements) that has a single property, an
> array of rootElement annotations.  That feels a little clunky, though.
> alternative would be to hang an array of rootElements on complexType, but
> that doesn't resolve the weirdness you point out.

The interesting thing is that in start-from-Java - there are probably two
reasons to define a global element, and perhaps we can have both the simple
and the clunky solution at once on the same globalElement (my name for it)

(1) There is a need for a single distinguished element to be used when
marshalling to a document
(2) And when unmarshalling, there is potentially a need to understand any
number of elements

so potentially globalElement could be its own annotation with two
properties, i.e., a singleton name and an optional array of additionalNames.

> >Also, you have the ability to specify the rootElement localname, but not
> >targetNamespace, which is 1/2 of the degrees of freedom available for the
> >global element definition name.  Would element targetNamespace be added
as a
> >knob in the future?
> Sure.

Yeah, this will be a pain in the neck if there are going to be arrays of
additionalNames, maybe to the point where there should not be
additionalNamespaces.  QNames are such a pain.

> >For my edification, how should targetNamespace be chosen by default?  Is
> >based on the package name, or is it a global setting on the command-line
> >the java->schema compiler?
> Yeah, currently, it will just synthesize a namespace from the package if
> there is no tns annotation.  However, I think it will be useful to allow
> users to give users a package-level annotation (which are formally
> supported in 175) to provide the tns for all of the classes in a package,
> or a command-line switch like you mention (which in some sense is a global
> annotation).  Most local scoping wins in the case of multiple tns
> annotations.  A tns would synthesized only in the absence of any tns
> annotations.
> Does that make sense?

Yes, noticed the package-level configuration in 175.

> >Finally, a couple details - you have element.exclude as a
> >kind of switch.  I think 175 is going to give us defaults, but when a
> >property is present, you'll have to specify a value, so seems like it
> In some ways, I think having a separate Exclude annotation makes more
> sense.  For one thing, it's much more compact.  More importantly, though,
> there isn't really much point in declaring the ComplexType annotation if
> it's going to be excluded anyway.  This will be especially true if we ever
> had a required property on an annotation type - you would have to specify
> dummy value even if exclude were true.

I had been thinking about property-exclude rather than type-exclude, but I
think your reasoning applies in both cases, and is also complimentary with
your reasoning about element versus attribute annotations.  It seems like in
both properties and classess Exclude should probably be its own annotation.


- ---------------------------------------------------------------------
To unsubscribe, e-mail:   xmlbeans-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xmlbeans-dev-help@xml.apache.org
Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/

View raw message