+1 to that.
As some background ... I created the WODEN-40 branch because I the
changes required for WODEN-40 are going to be quite big take more than
a day or two (elapsed). I thought either they can either develop on
my PC or they can develop in a branch where anyone can get involved.
So this is just a hint to the list that by creating a branch I hope to
generate more discussion because the code is developing on SVN and not
in private.
Cheers,
Jeremy
On 7/9/06, John Kaputin <[EMAIL PROTECTED]> wrote:
> I'd quite like to see the code develop in a branch...
Agreed. I was planning on raising a JIRA then creating a branch named with
the JIRA number, as per your recent approach.
John
"Jeremy Hughes"
<[EMAIL PROTECTED]
rg> To
Sent by: [email protected]
[EMAIL PROTECTED] cc
om
Subject
Re: [Vote] ElementSource to wrap
06/07/2006 15:09 element info items
Please respond to
[EMAIL PROTECTED]
he.org
I'd quite like to see the code develop in a branch where we don't need
to ensure all the unit tests pass all the time. I think this will make
it easier to see how this will work without disrupting the trunk.
Jeremy
On 7/6/06, Jeremy Hughes <[EMAIL PROTECTED]> wrote:
> Gah - John just noticed this thread having posted something similar on
> another. Will read later.
>
> Cheers,
> Jeremy
>
> On 7/6/06, John Kaputin <[EMAIL PROTECTED]> wrote:
> > Pierre,
> > The getContentModel() and getContent() methods on ElementDeclaration
and
> > TypeDefinition were intended for supporting different type system APIs
at
> > some point without tying the Woden API to any particular API like
> > ws-commons XmlSchema. getContentModel() indicates the type system API
being
> > used by a Woden implementation and based on this, the client
application
> > will cast the Object returned by getContent() to the appropriate type.
> >
> > Currently, the Woden implementation only supports the XmlSchema API, so
the
> > getContentModel() method reflects this by returning
> > "org.apache.ws.commons.schema" and the getContent() model returns an
Object
> > of type XmlSchemaElement or XmlSchemaType.
> >
> > Without pluggable support for type system APIs then we'd have no need
for
> > the getContentModel() and getContent() methods and instead just have
> > methods like ElementDeclaration.getXmlSchemaElement returning an
> > XmlSchemaElement and TypeDefinition.getXmlSchemaType returning an
> > XmlSchemaType.
> >
> > If Woden was using DOM to access the schema contents instead of
XmlSchema,
> > then the getContentModel() would return "org.w3c.dom" and the
getContent()
> > method would return an org.w3c.dom.Element. However, Woden uses
XmlSchema
> > for accessing schema contents.
> >
> > I proposed ElementSource to expose the DOM Element (or whatever)
> > representing the <xs:schema> element, but not for exposing the DOM
Elements
> > for any of the schema's elements declarations or type definitions. The
> > reason is that Woden has the same constraint that you face - it uses
> > XmlSchema to access the schema element declarations and type
definitions
> > and this API does not provide access to the DOM Elements. Woden has a
> > reference to the DOM Element for the <xs:schema> element at the time it
> > invokes XmlSchema, so my proposal was to expose this through the Woden
API
> > via the ElementSource and a Schema.getSchemaElement() method.
> >
> > A getSchemaElement() method on XmlSchema needs to be proposed on
> > [email protected], it's an XmlSchema issue rather than Woden
and
> > the return type of such a method could be simply org.w3c.dom.Element.
> >
> > regards,
> > John Kaputin
> >
> >
> >
> >
> > [EMAIL PROTECTED]
> > thalesgroup.com
> >
To
> > 06/07/2006 10:47 [email protected]
> >
cc
> >
> > Please respond to
Subject
> > [EMAIL PROTECTED] RE: [Vote] ElementSource to wrap
> > he.org element info items
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > ElementDeclaration would also need to be updated so that getContent()
would
> > return a ElementSource object and you could also provide a XmlSchema
> > specific method like getSchemaElement()...
> >
> > My 2 cents,
> > Pierre
> >
> > -----Message d'origine-----
> > De : John Kaputin [mailto:[EMAIL PROTECTED]
> > Envoye : jeudi 6 juillet 2006 16:35
> > A : [email protected]
> > Objet : [Vote] ElementSource to wrap element info items
> >
> >
> >
> > I'd like to propose creating a new 'wrapper' interface on the Woden API
> > similar in function to WSDLSource. WSDLSource wraps an implementation
> > specific object that represents the WSDL source being passed in to the
> > WSDLReader on a readWSDL(WSDLSource) method (e.g. for the DOM
> > implementation there is a DOMWSDLSource class that takes a DOM Element
or
> > Document or a SAX InputSource).
> >
> > I propose an interface org.apache.woden.ElementSource to represent an
> > implementation specific element information item object, such as a DOM
> > Element for the DOM implementation or an OMElement for the StAX/OM
> > implementation.
> >
> > It will have the methods:
> > public Object getElementSource() - this method will return an Object
which
> > the client must cast to the appropriate type.
> > public void setElementSource(Object) - the method implementation must
check
> > Object is an appropriate type and throw an exception if not.
> >
> > An example implementation will be
> > org.apache.woden.internal.DOMElementSource which wraps an
> > org.w3c.dom.Element.
> >
> > This can be used to replace org.w3c.dom.Element in method signatures on
> > XMLAttr, ExtensionDeserializer and ExtensionSerializer. This will meet
the
> > requirement from Oshani for her StAX/OM implementation to remove DOM
> > dependencies. She could create an implementation OMElementSource to
wrap an
> > OMElement.
> >
> > In this way we keep the Woden API 'clean' of any particular XML parsing
API
> > or object model.
> >
> > We can also use ElementSource to represent a <xs:schema> element from
any
> > underlying object model so that applications may use XML schema parsing
> > APIs other than ws-commons XmlSchema to manipulate schema data if they
> > choose. Their choice of schema parser would need to support the object
> > type(s) wrapped by ElementSource. Woden will still use XmlSchema and
> > expose this via it's API as it currently does.
> >
> > We would need to add a method to org.apache.woden.schema.Schema to
return
> > an ElementSource for the <xs:schema> element:
> > public ElementSource getSchemaElement().
> >
> > This may satisfy a couple of recent requirements against Woden for
> > alternatives to XmlSchema (most recently from Pierre Chatel, although
his
> > particular requirement could perhaps be solved by additions to
ws-commons
> > XmlSchema). A bigger solution might be pluggable type system support,
but
> > probably not any time soon due to other priorities and resources.
> >
> > Please discuss via this mailing list if you have any comments or
concerns.
> > I'll open a JIRA if/when this proposal is agreed.
> >
> > regards,
> > John Kaputin
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
