axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Reitzel, Charlie" <CReit...@arrakisplanet.com>
Subject RE: Encoding Architecture
Date Tue, 27 Feb 2001 23:36:50 GMT
I don't see why the 2.x NSStack doesn't work for this.  It produces clean
XML in that it doesn't produce extra NS decls, which I like.  It also
generates prefixes on the fly, if and as needed.  It's a stack 'o hash
tables, if I recall correctly.  Why not carry it forward?

-----Original Message-----
From: Sanjiva Weerawarana [mailto:sanjiva@watson.ibm.com]
Sent: Tuesday, February 27, 2001 2:06 PM
To: axis-dev@xml.apache.org
Subject: Re: Encoding Architecture


No, its other other way around; we're generating XML and need to
know what namespaces have been defined so far so that we don't
keep redefining SOAP-Enc, for example.

Sanjiva.

----- Original Message ----- 
From: "Doug Davis" <dug@us.ibm.com>
To: <axis-dev@xml.apache.org>
Sent: Tuesday, February 27, 2001 1:01 PM
Subject: Re: Encoding Architecture


> I know that's where we're using it, but don't the namespaces we use come
> from the XML stream?  If so, it seems like determining what namespaces are
> available to us at any point in the doc (or sub-doc in the case of
> deserialization)
> should be handled by the XML parser for us.
> -Dug
> 
> 
> "Sanjiva Weerawarana" <sanjiva@watson.ibm.com> on 02/27/2001 12:21:01 PM
> 
> Please respond to axis-dev@xml.apache.org
> 
> To:   <axis-dev@xml.apache.org>
> cc:
> Subject:  Re: Encoding Architecture
> 
> 
> 
> Its for use when you are generating XML (serializing/encoding); there is
> no XML parser involved.
> 
> Sanjiva.
> 
> ----- Original Message -----
> From: "Doug Davis" <dug@us.ibm.com>
> To: <axis-dev@xml.apache.org>
> Sent: Tuesday, February 27, 2001 9:06 AM
> Subject: Re: Encoding Architecture
> 
> 
> > Why isn't this handled by the XML parser?  Or are the current parsers
> > lacking in this area so we need to do it ourselves.
> > -Dug
> >
> >
> > "James Snell" <jsnell@lemoorenet.com> on 02/24/2001 05:55:39 PM
> >
> > Please respond to axis-dev@xml.apache.org
> >
> > To:   <axis-dev@xml.apache.org>
> > cc:
> > Subject:  Re: Encoding Architecture
> >
> >
> >
> > Getting back to this question... wouldn't a Hashtable work if the
> hashtable
> > contained all the currently inscope namespaces and nothing else?  The
> > Message API could keep track of what namespaces are currently inscope
> (the
> > proposed API that I posted earlier today already supports this notion).
> >
> > - James
> >
> >
> >
> >
> > ----- Original Message -----
> > From: "James Snell" <jmsnell@intesolv.com>
> > To: <axis-dev@xml.apache.org>
> > Sent: Friday, February 23, 2001 10:17 AM
> > Subject: RE: Encoding Architecture
> >
> >
> > > Ok, got it, understood. ;-)
> > >
> > > > -----Original Message-----
> > > > From: Glen Daniels [mailto:gdaniels@allaire.com]
> > > > Sent: Friday, February 23, 2001 10:15 AM
> > > > To: 'axis-dev@xml.apache.org'
> > > > Subject: RE: Encoding Architecture
> > > >
> > > >
> > > >
> > > > WRT the NSStack, the point is to have something that duplicates the
> > > > functionality of the 2.X version:
> > > >
> > > > You're writing an XML document, and the NSStack keeps track of what
> > > > namespaces have been declared with what prefixes in the
> > > > current scope.  So
> > > > as you move in and out of elements, you have a list of all in-scope
> > > > namespaces and their prefixes.  Thus you can opt to simply
> > > > use a predefined
> > > > prefix for a given namespace, instead of having to redeclare
> > > > the namespace
> > > > at the inner level.  This means the ability to push and pop
> > > > declaration
> > > > scopes.
> > > >
> > > > JDOM already has something like this, but it doesn't yet work
> > > > for prefixes.
> > > > I was planning to ping them about it soon, and if they don't
> > > > already have
> > > > plans to implement it, I'll do it and send them the patch.
> > > > That way if we
> > > > do end up settling on JDOM it'll already be available in there.
> > > >
> > > > --Glen
> > > >
> > > > > -----Original Message-----
> > > > > From: Steve Graham [mailto:sggraham@us.ibm.com]
> > > > > Sent: Friday, February 23, 2001 1:02 PM
> > > > > To: axis-dev@xml.apache.org
> > > > > Subject: RE: Encoding Architecture
> > > > >
> > > > >
> > > > > with regards to the NSSTack.  A hashtable cannot represent
> > > > the scoping
> > > > > rules needed to model the namespace scoping associated with
> > > > > this encoding
> > > > > problem.  Suggest that you use the Stack class (?java.util?)
> > > > >
> > > > > sgg
> > > > >
> > > > > ++++++++
> > > > > Steve Graham
> > > > > sggraham@us.ibm.com
> > > > > (919)254-0615 (T/L 444)
> > > > > Web Services Architect
> > > > > Emerging Internet Technologies
> > > > > ++++++++
> > > > >
> > > > >
> > > > > James Snell <jmsnell@intesolv.com> on 02/23/2001 12:00:16 PM
> > > > >
> > > > > Please respond to axis-dev@xml.apache.org
> > > > >
> > > > > To:   "'axis-dev@xml.apache.org'" <axis-dev@xml.apache.org>
> > > > > cc:
> > > > > Subject:  RE: Encoding Architecture
> > > > >
> > > > >
> > > > >
> > > > > Glen,
> > > > >
> > > > > Comments inline:
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Glen Daniels [mailto:gdaniels@allaire.com]
> > > > > > Sent: Thursday, February 22, 2001 10:19 AM
> > > > > > To: 'axis-dev@xml.apache.org'
> > > > > > Subject: RE: Encoding Architecture
> > > > > >
> > > > > >
> > > > > >
> > > > > > Hmm.
> > > > > >
> > > > > > James, I'm going to -1 this code for a variety of reasons:
> > > > > >
> > > > > > - It's not right to use SOAP-ENC:<type> (i.e.
> > > > > SOAP-ENC:string) - SOAP
> > > > > > encoding mandates the use of standard xsd: types.
> > > > > >
> > > > >
> > > > > From the SOAP Specification Section 5.2 :
> > > > >
> > > > > <snip>
> > > > >
> > > > >    If a simple value is encoded as an independent element or
member
> > > > >    of a heterogenous array it is convenient to have an element
> > > > >    declaration corresponding to the datatype. Because the
> > > > "XML Schema
> > > > >    Part 2: Datatypes" Specification [11] includes type definitions
> > > > >    but does not include corresponding element declarations, the
> > > > >    SOAP-ENC schema and namespace declares an element for
> > > > every simple
> > > > >    datatype. These MAY be used.
> > > > >
> > > > >    <SOAP-ENC:int id="int1">45</SOAP-ENC:int>
> > > > >
> > > > > </snip>
> > > > >
> > > > >
> > > > > > - Statements like new QName("axis", "t:tname") look a little
> > > > > > strange - are
> > > > > > you trying to imply that the resultant name is in the
> > > > > > namespace "axis" but
> > > > > > also has the prefix "t"?  Prefixes are a completely separate
> > > > > > issue - QNames
> > > > > > always contain the fully qualified name, and then
> > > > something else is
> > > > > > responsible for mapping the namespace URI in the QName into
a
> > > > > > prefix in a
> > > > > > particular XML document.
> > > > > >
> > > > >
> > > > > This is purely prototype code... I made no claims as to its
> > > > > perfection ;-)
> > > > >
> > > > > The "t:tname" was just a quick hack.
> > > > >
> > > > > > - I think the nsStack probably needs to be a little more
> > > > than just a
> > > > > > Hashtable.
> > > > > >
> > > > >
> > > > > Why?  All it does it map namespace and prefix.
> > > > >
> > > > > > - The DOM code is really heavyweight - I'd really like to
> > > > > give serious
> > > > > > consideration to using JDOM internally to represent our XML
> > > > > > structures; it's
> > > > > > MUCH MUCH easier to deal with (and cheaper) than DOM.
> > > > > >
> > > > >
> > > > > I'm all for doing something more lightweight than DOM... we
> > > > > just haven't
> > > > > collectively decided what that is yet.  In the meantime then,
> > > > > I used DOM.
> > > > >
> > > > > > - There doesn't seem to be an easy way to map individual
> > > > > > types like there
> > > > > > was with the Serializer/Deserializer pattern.
> > > > >
> > > > > Sure there is, look at the SOAPEncoderRegistry.  You can map
> > > > > individual
> > > > > data
> > > > > types to individual encoders/decoders.
> > > > >
> > > > > >
> > > > > > - The EncoderRegistry doesn't have the functionality of the
> > > > > > XMLJavaMappingRegistry, i.e. it doesn't allow multiple
> > > > > encoding-styles
> > > > > >
> > > > >
> > > > > I was actually thinking of a one-to-one relationship
> > > > between Encoding
> > > > > Styles
> > > > > and EncoderRegistry.  Why would this not be acceptable.
> > > > >
> > > > > > Granted I didn't really dig into it, so I may be missing
> > > > > > things, but this
> > > > > > code doesn't appear to be quite the right direction, IMHO.
> > > > > I think we
> > > > > > really need to have some more conversation about this area
> > > > > > soon, as it's
> > > > > > really important.
> > > > > >
> > > > > > Please let me know if you think I'm off-base here.
> > > > > >
> > > > > > --Glen
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: James Snell [mailto:jsnell@lemoorenet.com]
> > > > > > > Sent: Thursday, February 22, 2001 12:37 AM
> > > > > > > To: Steve Graham; Doug Davis
> > > > > > > Cc: axis-dev@xml.apache.org
> > > > > > > Subject: Encoding Architecture
> > > > > > >
> > > > > > >
> > > > > > > Ok... I've been playing around with some ideas for handling
the
> > > > > > > encoding/decoding of native types to XML for Axis and
> > > > > > > attached is a couple
> > > > > > > of ideas I've come up with.  This is a simplified version
> > > > > > > (IMHO) of the
> > > > > > > mechanism used by SOAP v2.x so it shouldn't be too difficult
> > > > > > > to grasp.  Take
> > > > > > > a look at the main.java class for an example of how to
use
> > > > > > > it.  If this
> > > > > > > looks good to everyone, I'll merge it into the codebase
> > > > > > this weekend.
> > > > > > >
> > > > > > > - James
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> >
> >
> >
> 
> 
> 

Mime
View raw message