Mailing-List: contact tuscany-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: tuscany-dev@ws.apache.org
Received-SPF: pass (athena.apache.org: domain of for.svkrish@gmail.com
 designates 72.14.204.235 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=VeBHGQ6svjDfIakaoQAvNeM3EHXDml9jamBfflny95LiN0TaZcfCz06MUwZ4NsjSr46lNZu/hbigcxgu2QkSYhsrRe/7915YMUePHXdl1FWcdzqObgIf3rNs31GMMQ8PzMgko8GPpmEz6blT0McIMEmTjs5TeO6EN/X4tSL22LY=
Message-ID: <33e260400802050658w60ff2c31ufa76b0f7d9467aa3@mail.gmail.com>
Date: Tue, 5 Feb 2008 20:28:49 +0530
From: "Venkata Krishnan" <for.svkrish@gmail.com>
To: tuscany-dev@ws.apache.org
Subject: Re: WSDLLess Deployment Implementation Question
In-Reply-To: <d4050d420802050640u6093ee74g4cf9eef05a740b38@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_13061_22137503.1202223529057"
References: <60d9c2b80801310904r7650e66fo7afa1377dd6f22aa@mail.gmail.com>
	 <71e1b5740802010633x3afa66bbi6db400862985451b@mail.gmail.com>
	 <47A639C7.4000106@gmail.com> <47A63E1A.7050606@apache.org>
	 <d4050d420802041100u23caee27vdb877bedc8e1c5ae@mail.gmail.com>
	 <47A82499.2090906@apache.org>
	 <d4050d420802050640u6093ee74g4cf9eef05a740b38@mail.gmail.com>

------=_Part_13061_22137503.1202223529057
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi Scott,

There was a discussion around this with the SDO folks and their view point
was that, having generated the static SDO from an XSD, why would one want to
go and generate the XSD again.  Ideally the original XSD should be used.

Its been a while since I've been thro this, but I do remember that the
discussion started after I had some trouble in getting back something
equivalent to the original XSD as part of this generation.  It was then
decided that we would provide these XSD locations as input arguments these
would be imported during the WSDL generation.

- Venkat

On Feb 5, 2008 8:10 PM, Scott Kurz <scottkurz@gmail.com> wrote:

> OK, just wanted to make sure I hadn't missed a discussion on how to do
> this with dynamic SDOs.
>
> You know, one issue I noticed when looking at this with static SDOs is
> the way that SDO makes it hard for you
> to programmatically go from static SDO to XSD.   Looking at the SDO
> source I think it was the code in
> org.apache.tuscany.sdo.helper.SchemaBuilder.buildSchema() which was
> responsible:
>
>                throw new IllegalArgumentException("Cannot generate
> XSD since SDO Type '" +
>                        dataType.getName() + "' was orginally
> generated from XSD.  Use original XSD");
>
>
>
>
>
> On Feb 5, 2008 3:55 AM, Jean-Sebastien Delfino <jsdelfino@apache.org>
> wrote:
> > Scott Kurz wrote:
> > > When you wrote:
> >  >
> > > - The generator should use the databinding metadata (including any
> > > knowledge of handwritten XSD representing the business data and
> > > generation capabilities like the SDO XSDGenerator) to generate proper
> > > XSD in the WSDL.
> > >
> > > How were you thinking a particular XSD would be associated with a
> > > generic DataObject on a Java intf?    What
> > > metadata would we be using as input here?
> > >
> > [snip]
> >
> > I was thinking about static SDOs.
> >
> > Java method updateCustomer(DataObject anObject) would translate to
> > WSDL operation updateCustomer [ XSD xsd:any ]
> >
> > but Java method updateCustomer(Customer customer) would translate to
> > WSDL operation updateCustomer [ XSD cust:Customer ]
> >
> >
> > --
> > Jean-Sebastien
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>

------=_Part_13061_22137503.1202223529057--