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]
