16 messages in org.apache.xmlbeans.userRe: Creating complexType objects...
FromSent OnAttachments
Kent SpauldingJul 26, 2005 11:47 am 
Don StewartJul 27, 2005 1:58 am 
Caroline WoodJul 27, 2005 2:01 am 
Kent SpauldingJul 27, 2005 8:05 am 
Cezar AndreiJul 27, 2005 9:55 am 
Dave HarrisonJul 27, 2005 10:09 am 
stephJul 27, 2005 10:41 am 
Dave HarrisonJul 27, 2005 11:09 am 
Kent SpauldingJul 27, 2005 11:28 am 
Stephane MorucciJul 27, 2005 11:29 am 
Kent SpauldingJul 27, 2005 11:44 am 
Cezar AndreiJul 27, 2005 2:10 pm 
Dave HarrisonJul 27, 2005 2:44 pm 
Kent SpauldingJul 27, 2005 3:31 pm 
Dave HarrisonJul 28, 2005 5:43 am 
Kent SpauldingJul 28, 2005 9:56 am 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:Re: Creating complexType objects...Actions...
From:Kent Spaulding (Kent@Sun.COM)
Date:Jul 27, 2005 11:44:10 am
List:org.apache.xmlbeans.user

That Cezar -

This definately helps me understand what is going on.

I still find it a little frustrating that I cannot construct a 3) from an 'interior' type (i.e. no *Document class); without knowing either an enclosing element name from some doc-type that uses these; or the QName to use.

I don't care if they parse right away (and besides, I can make them parse with the right namespace decl) - I want to do this so I can place these in a parent node/element that is typed as xs:any.

Anything XmlBeans could do to make xs:any support easier, even if it is just through convienence classes that assume some pattern of xs:any usage would be very helpful.

As an example of a pattern, all the objects in a schema that have an xs:any element inherit from a base type like:

<complexType name="ExtensibleType"> <sequence> <any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax"/> </sequence> <anyAttribute namespace="##other" processContents="lax"/> </complexType>

which means that xs:any elements are always the first elements in any type that extends. This makes it deterministic as to where to insert and where to read these 'extrinsically' typed elements. One could imagine an extension to support this idiom - sort of like JAXB's support.

Thanks for listening, and helping, --Kent

Cezar Andrei wrote:

Kent,

The XmlObject interface always represents the content, it does not represent the node itself as in DOM. There are three different types of XmlObject: 1) content of an element: i.e. attributes, inner elements and inner text, without the element name. 2) simple type content: i.e. text, can be the content of an attribute, or a text only element. The java objects representing this type of content will implement SimpleValue interface. 3) content of a document: i.e. only one root element. The corresponding java type will have the suffix 'Document' in the name.

For 3) XmlObject.toString() will return the entire document representation. But for 1) and 2), because they represent inner parts of a document, XmlObject.toString() will insert the representation of the content inside an <xml-fragment> element, so it can be parsed by any xml parser. There are options to change the name of the 'xml-fragment' name: XmlOptions.setSaveSyntheticDocumentElement(QName name) and XmlOptions.setSaveOuter().

I hope this helps you. Cezar