xml-xmlbeans-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Vasilik" <eric...@bea.com>
Subject RE: get/set methods for <xsd:any> element
Date Wed, 10 Mar 2004 09:30:56 GMT
These methods should not be prefixed with "get".  They can conflict with
schema generated methods.  I suggest:

    selectChildren ( ... )
    selectAttributes ( ... )
    selectAttribute ( ... )

I choose "select" prefix because there is a precedent of the existing
method on XmlObject already:

    selectPath( ... )

These new select methods are convenience methods for the, more powerful,
selectPath method.

- Eric

-----Original Message-----
From: Cezar Andrei 
Sent: Tuesday, March 09, 2004 4:05 PM
To: xmlbeans-dev@xml.apache.org
Subject: RE: get/set methods for <xsd:any> element

Giving the fact that a solution should not do validation for pref and
stability reasons discussed earlier and also having predictable results
for any instance, I'd like to propose as a solution the addition of the
following methods on XmlObject:

XmlObject[] getChildren(QName qname);
XmlObject[] getChildren(String uri, String localName);
XmlObject[] getChildren(QNameSet qnameSet);

They will return the content of all elements that have the given name or
are contained in the qnameSet.

For attributes:
XmlObject getAttribute(QName qname);
XmlObject getAttribute(String uri, String localName);
XmlObject[] getAttributes(QNameSet qnameSet);

QNameSet can represent a set of QNames, it can represent ##any qnames.
Or ##other and ##targetNamespace for a given target namespace. Or any
set of qnames because QNameSet supports set operations like union,
intersect and invert.

This doesn't solve any case related to wildcards but for less usual
cases there are other ways to get to the needed attributes or elements: 
   - selecting an xpath.
   - navigate with XmlCursor.
   - and soon the ability to get to the DOM nodes.

I'd like to hear your opinion if this solution is (or is not) solving
your concrete cases?

Cezar

> -----Original Message-----
> From: Wolfgang Hoschek [mailto:whoschek@lbl.gov]
> Sent: Friday, February 20, 2004 7:29 PM
> To: xmlbeans-dev@xml.apache.org
> Subject: Re: get/set methods for <xsd:any> element
> 
> 
> Yep, I voted for (B).
> 
> What you suggest below would work fine for us as well, the ambigous 
> corner cases discussed in this thread simply don't come up in 
> our practice.
> 
> Wolfgang.
> 
> David Bau wrote:
> > I think we should be guided by the "element declarations
> > consistent" rule in the schema specification requires that
> > any definition for <foo> be of exactly the same type, even
> > if it's pulled in via a wildcard.  (I've asked the W3C XSWG
> > to clarify this fact on the email lists
> > 
> http://lists.w3.org/Archives/Public/www-xml-schema-comments/20
> 03OctDec/0029.html)
> > 
> > This rule strongly suggests that the meaning of <foo>
> > shouldn't change whether or not it happens to be pulled in
> > via wildcard, or whether it's matched by a particular
> > <choice> branch or substitution group.  A <foo> should mean
> > the same thing no matter what different elements surround it
> > and in what order.
> > 
> > So...  XMLBeans currently takes advantage of this rule so
> > that when you say getFooArray(), it returns _all_ elements
> > <foo>, even if one or more of them happen to be matched by
> > <any> or substitution group or some combination of
> > <choice>s.  XMLBeans does not validate to bind.
> > 
> > As I mentioned in the last email, I think that whatever
> > method we have for getOtherArray() should have similar
> > by-name-binding behavior, i.e., if "foo"s are in the
> > recognized element set, getOtherArray shouldn't return
> > "foo"s.
> > 
> > The thing I'd like to really avoid is forcing validation to
> > occur for any binding.  Why?  Because it's fragile and
> > expensive, and the schema spec has a rule (EDC) that is
> > explictly designed to avoid making validation necessary for
> > binding.  We should take advantage of it.
> > 
> > David
> > 
> > 
> > ----- Original Message ----- 
> > From: "Radu Preotiuc-Pietro" <radup@bea.com>
> > To: <xmlbeans-dev@xml.apache.org>
> > Cc: <davidbau@hotmail.com>
> > Sent: Thursday, February 19, 2004 9:21 PM
> > Subject: [xmlbeans-dev] RE: get/set methods for <xsd:any>
> > element
> > 
> > 
> > If we go down this path, then what if we modify David's
> > example to the following:
> > 
> > <xs:complexType name="base">
> >    <xs:sequence>
> >       <xs:any namespace="##targetNamespace" maxOccurs="2"/>
> >    </xs:sequence>
> > </xs:complexType>
> > 
> > <xs:complexType name="derived">
> >    <xs:complexContent>
> >      <xs:restriction base="base">
> >        <xs:sequence>
> >          <xs:element name="foo"/>
> >          <xs:any namespace="##targetNamespace"/>
> >        </xs:sequence>
> >      </xs:restriction>
> >    </xs:complexContent>
> > </xs:complexType>
> > 
> > This is still a valid restriction, but what will the
> > Derived.getAnyArray() return?
> > (suppose we have <foo/><foo/> in the instance document)
> > Two elements of type Foo, or just one? If two, how do you
> > then know how many <foo/> elements you had in the instance
> > document?
> > This is a strange issue...
> > Radu
> > 
> 
> 
> - 
> ---------------------------------------------------------------------
> 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/
> 
> 

- ---------------------------------------------------------------------
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/


- ---------------------------------------------------------------------
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/


Mime
View raw message