A few questions: #1: Can you please open a bug report with a pointer to the schema that fails? #2: Did you try using any JAXB implementation against the schema?
thanks, dims On Fri, 14 May 2004 12:03:14 -0400, Jeff <[EMAIL PROTECTED]> wrote: > > Hi! > > On a similar note, there's a disconnect between the capabilities of tools > created by the software industry and the requirements of the scientific > community. > > I have just completed a particular type of Open GIS Consortium (OGC) web > service called a Sensor Collection Service. The XML Schema referenced from > the WSDL file comprises 54 XML Schema documents spanning 15 namespaces. Not > only did the Axis bean code baulk at this but, when I had completed the > project, clients found that the .NET tools couldn't handle anything like the > complexity of the SCS XML Schema. Consequently, I supplied 'client > software'. > > The originators of SOAP are conning the software world and no one seems to > mind! > > If it's legitimate to distribute platform-independent data (XML) it must be > legitimate to distribute the program logic that uses that data. If only we > had a platform-independent way to deliver program logic! > > Forcing web service clients, as a matter of fiat, to write their own program > logic is the antithesis of OOP: interfaces, inheritance, polymorphism all > exits to promote reuse. Reuse is the Holy Grail of software development. > > It could be argued that each client has their own needs and so it's not > possible to write generic client-side code. Such an argument is false. The > fact that XML Schemas are used to formalise the data transmitted within SOAP > envelopes means that each web service is necessarily application-specific > and, as such, is tractable to low-level client code. Such code exposes data > (in the form of XML, if appropriate) that can then be used in whatever way > the ultimate consumer-code requires. > > I recently wrote a web service for the Government of Canada that provided > document-literal content in the form of Web Ontology Language (OWL). > Everyone was pleased with the outcome and loved the OWL implementation BUT > the first thing they did was to nominate someone to write a generic client > that dealt with the XML and provided the desired content through a Java > component that everyone could use/reuse. Hey, that's an idea...I wonder if > we could supply Java client-side code with our web services. That way, the > .NET folks and all other non-Java folks could continue to do what they do > and the sane software developers can get back to the preferred paradigm of > using portable code. > > XML and Java go together. Sun and all other interested parties seem to be > blind to the fact that making portable client-side code an integrated web > service deliverable would make those services far more viable. Not everyone > wants to get into WSDL, etc. when they could simply use a bean! SOAP and web > services are infrastructure. Folks who use my web services want turnkey > solutions. For them it's about access to scientific data. They want to > operate at a higher level of abstraction than SOAP! > > Warmest regards, > > Jeff > > Cogent Logic Corporation > > Toronto, Canada > > ----- Original Message ----- > From: "Galbreath, Mark A" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Friday, May 14, 2004 11:22 AM > Subject: RE: Project from hell? > > > EXACTOMUDO! :-( > > > > -----Original Message----- > > From: Sherman, Dennis (END-CHI) [mailto:[EMAIL PROTECTED] > > Sent: Friday, May 14, 2004 9:12 AM > > > > Your task sounds to me suspiciously like someone at an executive level > > having heard about web services, and thinking they've found the silver > > bullet to all their problems. > >
