Return-Path: Delivered-To: apmail-xml-axis-dev-archive@xml.apache.org Received: (qmail 79669 invoked by uid 500); 23 Apr 2002 10:51:36 -0000 Mailing-List: contact axis-dev-help@xml.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-dev@xml.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list axis-dev@xml.apache.org Received: (qmail 79660 invoked from network); 23 Apr 2002 10:51:36 -0000 Message-ID: <026d01c1eab4$d7e22720$9418038a@uk.oracle.com> From: "Tim Blake" To: Subject: JavaBeans and metadata Date: Tue, 23 Apr 2002 11:51:36 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_026A_01C1EABD.38EC8DF0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N This is a multi-part message in MIME format. ------=_NextPart_000_026A_01C1EABD.38EC8DF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Could somebody please give me a summary of the design decisions taken = vis-a-vis storing metadata inline with generated complexTypes? I = appreciate that this has already been the subject of some discussion = (and maybe even disagreement ;-)) and I'm genuinely trying to = understand, not just rock the boat... - Why do you store metadata inline, as opposed to in separate files (or = maybe this is possible as well)? - Why do you use "org.apache.axis.description.TypeDesc" for describing = metadata on JavaBeans, rather than the existing BeanInfo framework? Is = this intended to be more generic than BeanInfo, since it can be used in = other contexts? How does this "proprietary" metadata layer affect the = use case where people want to publish existing JavaBeans without = modifying them? My real interest here is in solving the problem of mapping the XML = schema comparators all | sequence | choice into Java in the best = possible non-AXIS-specific way. This isn't so much a question of = "interoperability" as "uniformity" of solution. If you've discussed = this to death previously then please point me to the relevant posts. If = not, what do y'all think? Thanks, Tim ------=_NextPart_000_026A_01C1EABD.38EC8DF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

Could somebody please give me a summary = of the=20 design decisions taken vis-a-vis storing metadata inline with generated=20 complexTypes? I appreciate that this has already been the subject = of some=20 discussion (and maybe even disagreement ;-)) and I'm genuinely = trying to=20 understand, not just rock the boat...

- Why do you store metadata inline, as = opposed to=20 in separate files (or maybe this is possible as well)?

- Why do you use=20 "org.apache.axis.description.TypeDesc" for describing metadata on = JavaBeans,=20 rather than the existing BeanInfo framework? Is this intended to = be more=20 generic than BeanInfo, since it can be used in other contexts? How = does=20 this "proprietary" metadata layer affect the use case where people want = to=20 publish existing JavaBeans without modifying them?

My real interest here is in solving the = problem of=20 mapping the XML schema comparators all | sequence | choice into Java in = the best=20 possible non-AXIS-specific way. This isn't so much a question of=20 "interoperability" as "uniformity" of solution. If you've = discussed this=20 to death previously then please point me to the relevant posts. If = not,=20 what do y'all think?

Thanks,

Tim

------=_NextPart_000_026A_01C1EABD.38EC8DF0--