compile time generation of XmlElement//Attribute for interface types [Re: XmlObject and XML Infoset

[Aleksander Slominski <as...@cs.indiana.edu>]

hi Eric,

thanks for answers! they are very helpful to understand XmlBeans design 
choices. still i have more quesitons.

Eric Vasilik wrote:

>Marking the generated interfaces in such a manner is not generally
>possible.  For global elements and anonymous schema types, this can
>work.  But for global element document types and global attribute
>document types, as well as global types, the association cannot be made
>a compile time.
>  
>
but you still know what they are Element and Attribute Information Items 
(or can be only mapped to) at *compilation* time right ?

so is the problem in the backing store? if backing store was closer to 
DOM tree would it be easier?

>XmlBeans generates XmlObjects which are instances of *types* --
>generally independent from where that type is used.  So, you could have
>an interface Foo (which extends XmlObject) which can simultaneously
>represent the value of an attribute as well as the value of an element.
>  
>
could you give an example schema for this case so i could look on what 
happens in XmlBeans?

what i do not understand (i am not XML schema expert ...) how Foo can be 
declared to be both <xs:element/> and <xs:attribute/>? i am *only 
*interested in concrete XML Schema types (and not abstract ones) as 
those are the only types that i think are actually mapped to XML Infoset?

i some sense what i am asking for is to take *SchemaLocalElement *(and 
friends) and to make them part of generated interface instead of relying 
on reflection *(*XmlObject.schemaType() which is declared as permanent, 
unchanging schema type  ...

i prefer to write code that deals with XML Infoset and is strongly types 
as in:

foo(XmlElement) {
}

instead of

foo(XmlObject o) {
    if(o.schemaType().getComponentType() == SchemaComponent.ELEMENT )  
|| /* other missing conditions i do not understand - XmlCursor?*/) {
       // ok this is XmlElement
     } else {
           throw new IllegalArgumentException("expected XML Infoset 
Element Information Item and not "+o.xmlText());
     }
}


and i think doing
foo(XmlTokenSource) {}
foo(XmlCursor) {}
would lead to more ugly runtime checks/casts ...


>These generated interfaces (XmlObject based) are meant to abstract the
>user away from the "raw" XML, and let the user interact with an instance
>in terms of the schema.
>  
>
generating Foo that implements XmlAttribute (for Attribute Information 
Item) and XmlObject interfaces will make no difference to  user 
interactions AFAICT?

>With respect to an XmlCharacter marker, I assume you mean to effectively
>mark DOM text nodes.  XmlObjects are not created for XML Infoset
>character content.  They may only be associated with elements,
>attributes and documents. 
>
how text content is represented then when it is the content of XmlObject 
(for example for mixed content)?

it is not longer XmlObject derived?!

> Now, one could mark all simple content with
>types with this marker, but I'm not sure what that buys you.
>
>For TokenType (I assume you mean XmlCursor.TokenType) -- these are
>static members of XmlCursor which are used to allow one to identify what
>kind of token an XmlCursor is currently positioned near.  There is no
>relationship between these and XmlObject.
>  
>
i am confused: isnt XmlCursor really backing what XmlObject represent so 
they *are* related?

>If you want to find out what kind of XML Infoset item is referred to by
>a given XmlObject, you can get an XmlCursor from it and ask it what kind
>of XML Infoset item it's on.
>  
>
how to deal with this use case: i would like to be able to write code 
that process XML Infoset and can *if* needed (or *when* present) to 
process XML Schema types. so in this case i want method to take XML 
Element Information Item  (think for example SOAP body message first 
child element) and would be good if the element can be cast to XmlObject 
*if* there is databinding but still allow processing in case when no XML 
Schema is available.

this looks to me like a common case when processing XML documents that 
contains mix of multiple XML Schemas or when doing messaging.

>The interface extension feature is a way for one to have various
>generated XmlObjects implement user defined interfaces.  When the schema
>is compiled, you would specify which generated classes should implement
>which interfaces.  Similar to what I described above, there is no way to
>identity, at compile time, which objects will be elements/attributes.
>  
>
how difficult it is to inject into XmlBeans v1 generator ability to 
recognize <xs:element> (and such) and make generated class implement 
XmlElement whenit can be determined that Foo will be always backed by 
XML Infoset Element Information Item?

thanks,

alek
ps. of course i am thinking about it as an optional feature if there is 
some mismatch between XmlBeans design goals and exposing XmlInfoset 
properties (in generated interfaces) in a a statically typesafe way (and 
not relfection ...)

>-----Original Message-----
>From: Aleksander Slominski [mailto:aslom@cs.indiana.edu] 
>Sent: Tuesday, April 27, 2004 6:59 PM
>To: xmlbeans-dev@xml.apache.org
>Subject: XmlObject and XML Infoset
>
>hi,
>
>as far as i understand everything in XmlBeans extends XmlObject? i would
>
>like to add to XmlBeans a marker interface XmlElement that is 
>implemented by XmlObject only when XmlObject represents XML Infoset 
>Elements Information Item (irregardless of what is inside eii). 
>Similarly i would like to have a marker XmlCharacter interface for 
>XmlObjects that represent XML Infoset character content. i am not 
>exactly sure what is relation between TokenType and XmlObject.
>
>so is it possible? probably yes :) as of course there is source code to 
>hack in the worst case ...
>
>but to be more specific is it possible in v1 with 
>ExtensionInterfacesFeature that Cezar Andrei created?
>
>if not how much work would be required to do it in some other way?
>
>thanks,
>
>alek
>
>  
>


-- 
The best way to predict the future is to invent it - Alan Kay


- ---------------------------------------------------------------------
To unsubscribe, e-mail:   xmlbeans-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xmlbeans-dev-help@xml.apache.org
Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/