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]
