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: Start-with-java annotations
Date Fri, 14 Nov 2003 22:03:11 GMT
Hi pcal -

Yup, you're right

(1) Agreed that the wiki ones should be xmlbeans:property rather than
xmlbeans:binding, since there will be other things to annotate.  I'll update
the wiki.

(2) Agreed that the annotations in the wiki are just a start and we will
need more.  I'll check in scott's list in a "designnotes" area (do you think
should it be in v2/ or the website?) and refer to it. I like scott's list
because he covers a lot, but I guess I don't agree that every annotation in
scott's list is important/desirable.  I'm a bit more comfortable working up
from a very small list (using the longer list as a guide perhaps).

Here's an example - the longer list includes all the simple type facets as
annotations you can do on specific properties - I suppose those would
generate into a schema with nested anonymous simple type definitions.  But
it feels to me like that's not a great kind of schema to encourage people to
generate.  Normally folks who are doing custom simple types will give them
actual type name, and then use the same simple types in different parts of
their schema.  I don't know if there is any good way of doing this via
annotations, but I'm pretty sure it's not very good to encourage people to
define an anonymous and distinct custom "5-digit number" type every time
they have a zipcode.  Then, in terms of the schema type definitions, every
zipcode in their schema will be type-incompatible (not substitutable) with
every other zipcode.

I'm more comfortable building up from a small set annotations.


----- Original Message ----- 
From: Patrick Calahan
To: xmlbeans-dev@xml.apache.org ; xmlbeans-dev@xml.apache.org
Sent: Wednesday, November 12, 2003 2:34 PM
Subject: [bea-readme] Re: Start-with-java annotations

At 11:06 AM 11/12/2003 -0500, David Bau wrote:

Pcal and the rest of dev team -

I've put together a short wiki with some Java annotations that we probably
want to use in the start-with Java case for XMLBeans v2:


They provide, e.g., the ability to exclude a property from binding; to
specialize to a specific subclass of the declared type of a property; to
change names, use attributes, configure arrays.

Please feel free to annotate the wiki with clarifications, questions,
comments, additions.

Hey David.  That's great, thanks a lot for writing that up, that's a great
start.  I do think there are a number of additional tags we will need,
however.  Scott wrote up a pretty complete list a while back which I have
attached to this email - didn't we take a look at this before?

Anyway, I've been trying to post this list on the wiki, but it is in html
and I'm having a devil of a time getting the wiki to deal with it.  I gather
that this has not been ensabled in the server, which is a bit annoying.  If
worse comes to worse, I'll just start editing it by hand, but that's pretty

Some questions about annotations in general.

(1) Do you think we're going to be moving our annotation use to JSR 175 (JDK
1.5) for v2?  I know we've got support for annoations-in-javadoc right now.
What is Sun's timeframe for 1.5 anyway?  I think that if it fits, we should
plan on it.

I don't know that Tiger has a firm release date yet; last I heard was
mid-year 2004.  We may see a preview release by year's end that contains all
of the 175 stuff.  It's entirely today to write a JAM-filler that reads the
classfile annotations, and then we can test it against 1.5 javac as it
becomes available.  Probably not a super-high priority, but I agree it would
definitely be a good thing to have.

On that note, though, I think we need to be careful to make sure that the
javadoc annotations are structured in such a way as to be consistent with
the 175 model.  The primary motivation for getting these things to line up
nicely is that if we do it correctly, the java2schema processor will be able
to navigate the annotation tree by name, never knowing whether the
annotations are in fact javadoc style or 175-style - the structures
presented to the processor by JAM will be identical in either case.

With that in mind, I think we may want to adjust the naming convention you
have on your tags.  All of the tags are on an annotations called
'xmlbeans:bind,' which means that we will have a single 175 Annotation type
called 'bind.'  I think it may make more sensse to have several different
annotations types that are focused on a specific context, e.g. a property or
a type.  The annotations in Scott's list are divided up this way, and I
think it makes sense.  This especially true since 175 allows one to target a
given Annotation type at particular java constructs (method, class, field) -
it will just help us tighten down our annotation space a little.

(2) I notice we're currently processing source code to extract annotations,
but I believe the JSR 175 model is for a compiler to compile the annotations
into .class files which are then processed afterwards.  So that suggests
that we shouldn't be processing Java source code, but rather compiled
classes?  Is somebody here familiar enough with 175 to say if that is

That is correct, but 175 will also support the 'source-only' annotations
which are retrieved via extensions to the doclet API but which are not
persisted as classfile annotations.  This is part of the reason I think JAM
will continue to be useful in the post-175 world - 175 does not provide a
unified access API.


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

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