You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by David Jencks <da...@yahoo.com> on 2006/06/16 23:24:58 UTC
Namespace-driven builders and the UPA rule
For the pluggable jacc implementation (GERONIMO-1563)
I've been working on making a basic namespace-driven
builder framework. The code is simple and looks like
it will work fine but..... there's a problem with the
schema unique particle attribute rule, which basically
says that in order for a schema to be valid each
element can only be parsed in one way, and the way
must be determined without looking forward or
backwards or looking very hard at the context.
OK. So, I wanted to make the geronimo security
element namespace-driven, so if you used the current
security-1.1 namespace you'd get our current impl, if
you used something else you'd get that impl. We had
...
<xs:element name="ext-module"
type="geronimo:ext-moduleType" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element ref="security:security"
minOccurs="0"/>
<xs:element ref="sys:gbean" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
In order to make the security element variable, it
needs to be <xs:any namespace="##other"
minOccurs="0:/>
Then in order to prevent the first gbean matching this
if there's no security element I have to make the
gbeans work through namespace driven builder too, and
get
...
<xs:element name="ext-module"
type="geronimo:ext-moduleType" minOccurs="0"
maxOccurs="unbounded"/>
<xs:any namespace="##other"
processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
This works fine for the geronimo-application schema
the problem comes with the web schemas (and perhaps
the openejb schema, I haven't got that far yet). We
now have
<xs:group
ref="naming:jndiEnvironmentRefsGroup"/>
<xs:element
ref="naming:message-destination" minOccurs="0"
maxOccurs="unbounded"/>
<xs:sequence minOccurs="0">
<xs:element name="security-realm-name"
type="xs:string"/>
<xs:element ref="security:security"
minOccurs="0"/>
</xs:sequence>
<xs:element ref="sys:gbean" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
With a similar combination as in the g-app schema we'd
get:
<xs:group
ref="naming:jndiEnvironmentRefsGroup"/>
<xs:element
ref="naming:message-destination" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="security-realm-name"
type="xs:string" minOccurs="0"/>
<xs:any namespace="##other"
processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
if the security-realm-name element was required
there'd be no problem, you could tell that the naming
elements are not part of the anys at the end. However
if it is missing, the naming elements could match the
explicit elements or the anys.
I don't know how to get by this problem. xmlbeans has
a no-upa option which might let use use this schema,
but it's an invalid schema, so this is not completely
desirable. We could turn the entire schema into a
bunch of anys, but this sort of loses the point of
having a schema. We could make an incompatible change
to the schema, or we could special case the current
security namespace and effectively introduce another
element to hold other builders security info,
something like
<xs:sequence minOccurs="0">
<xs:element name="security-realm-name"
type="xs:string"/>
<xs:choice>
<xs:element
ref="security:security" minOccurs="0"/>
<xs:element
ref="security:security-holder" minOccurs="0"/><!--
holds other peoples security element -->
</choice>
</xs:sequence>
(I'm not sure this is a legal schema bit)
I'm going to try out the noupa option first but I'm
hoping someone will come up with a generally better
approach.
thanks
david jencks
Re: Namespace-driven builders and the UPA rule
Posted by David Jencks <da...@yahoo.com>.
On Jun 18, 2006, at 1:55 PM, Gianny Damour wrote:
> Hi,
>
> Is there a way to do this substitution of JACC implementation by
> providing a substitutionGroup attribute to the security element?
<giant snip>
I think this is the best solution, although there are some problems.
It appears that substitution groups may not really be intended to
provide runtime-extensible element support, at least xmlbeans doesn't
work that way. I think I have a solution.
Xmlbeans' ideas about substitution groups are that it only recognizes
the substitutions that are in the set of schemas compiled at the same
time as the element being substituted for. Later schemas compile
just fine but the list of substitute qnames is hardcoded in the
generated code for the substitutable element and also in the binary
xsb encoding of the schema. It might be possible to add more qnames
into the object model the xsb is deserialized into, but I don't see
a reasonable way to modify the hardcoded list in the generated code.
What I've come up with that appears to work is:
- use substitution groups in the schemas. This makes it plausible to
see what is intended, unlike with the use of any.
- track substitution group elements ourselves, so we can dynamically
change recognized substitution groups as builders are added. I'm
less sure about tracking removing builders. In this case the
elements wouldn't get deployed but we wouldn't get an error.
- modify our response to validation failures to ignore those caused
by unrecognized substitution group elements
- use the XmlObject.selectChildren(QNameSet) method to get the
substitution group elements based on our tracking of the QNames in
the substitution group.
I hope to iron out the remaining wrinkles shortly and submit an
updated patch for review.
thanks
david jencks
Re: Namespace-driven builders and the UPA rule
Posted by David Jencks <da...@yahoo.com>.
I'll have to investigate this more. I'm not very
familiar with substitution groups. If we can make
this work, I think it would take care of at least some
of Aarons concerns about anys, although for a generic
build structure we might end up with something similar
to anys. I don't like anys either, so I'm pretty
motivated to look into this :-)
I think the application-name is obsolete and should be
removed.
Thanks
david jencks
--- Gianny Damour <gi...@optusnet.com.au>
wrote:
> Hi,
>
> Is there a way to do this substitution of JACC
> implementation by
> providing a substitutionGroup attribute to the
> security element?
>
> This may be not be correct; yet, this could look
> like this:
>
> <xs:complexType name="security">
> <xs:sequence>
> <xs:element ref="security:security"
> minOccurs="0"/>
> </xs:sequence>
> </xs:complexType>
>
> <xs:complexType name="pluggable-security">
> <xs:complexContent>
> <xs:extension base="geronimo:security"/>
> <xs:sequence>
> <xs:element
> name="jacc-implementation"
> type="xs:string"/>
> </xs:sequence>
> </xs:extension>
> </xs:complexContent>
> </xs:complexType>
>
> <xs:element
> substitutionGroup="geronimo:security"
> name="pluggable-security"
> type="geronimo:pluggable-security"/>
>
> <xs:complexType name="applicationType">
> <xs:sequence>
> <xs:element ref="sys:environment"/>
>
> <xs:element name="module"
> type="geronimo:moduleType"
> minOccurs="0" maxOccurs="unbounded"/>
> <xs:element name="ext-module"
> type="geronimo:ext-moduleType"
> minOccurs="0" maxOccurs="unbounded"/>
> <xs:element name="security"
> type="geronimo:security"
> minOccurs="0"/>
> <xs:element ref="sys:gbean"
> minOccurs="0"
> maxOccurs="unbounded"/>
> </xs:sequence>
>
> <!--TODO application name should be settable
> using name-key in
> the environment. Does this work? -->
> <xs:attribute name="application-name"
> type="xs:string"
> use="optional"/>
> </xs:complexType>
>
> I think that this approach is more verbose than the
> namespace-driven
> approach; however, it is then easier to read the
> schema and understands
> how to swap the JACC implementation.
>
> Thanks,
> Gianny
>
> David Jencks wrote:
>
> >For the pluggable jacc implementation
> (GERONIMO-1563)
> >I've been working on making a basic
> namespace-driven
> >builder framework. The code is simple and looks
> like
> >it will work fine but..... there's a problem with
> the
> >schema unique particle attribute rule, which
> basically
> >says that in order for a schema to be valid each
> >element can only be parsed in one way, and the way
> >must be determined without looking forward or
> >backwards or looking very hard at the context.
> >
> >OK. So, I wanted to make the geronimo security
> >element namespace-driven, so if you used the
> current
> >security-1.1 namespace you'd get our current impl,
> if
> >you used something else you'd get that impl. We
> had
> >
> >...
> > <xs:element name="ext-module"
> >type="geronimo:ext-moduleType" minOccurs="0"
> >maxOccurs="unbounded"/>
> > <xs:element ref="security:security"
> >minOccurs="0"/>
> > <xs:element ref="sys:gbean"
> minOccurs="0"
> >maxOccurs="unbounded"/>
> > </xs:sequence>
> >
> >In order to make the security element variable, it
> >needs to be <xs:any namespace="##other"
> >minOccurs="0:/>
> >
> >Then in order to prevent the first gbean matching
> this
> >if there's no security element I have to make the
> >gbeans work through namespace driven builder too,
> and
> >get
> >...
> > <xs:element name="ext-module"
> >type="geronimo:ext-moduleType" minOccurs="0"
> >maxOccurs="unbounded"/>
> > <xs:any namespace="##other"
> >processContents="lax" minOccurs="0"
> >maxOccurs="unbounded"/>
> > </xs:sequence>
> >
> >This works fine for the geronimo-application schema
> >
> >the problem comes with the web schemas (and
> perhaps
> >the openejb schema, I haven't got that far yet).
> We
> >now have
> >
> > <xs:group
> >ref="naming:jndiEnvironmentRefsGroup"/>
> > <xs:element
> >ref="naming:message-destination" minOccurs="0"
> >maxOccurs="unbounded"/>
> >
> > <xs:sequence minOccurs="0">
> > <xs:element
> name="security-realm-name"
> >type="xs:string"/>
> > <xs:element ref="security:security"
> >minOccurs="0"/>
> > </xs:sequence>
> >
> > <xs:element ref="sys:gbean"
> minOccurs="0"
> >maxOccurs="unbounded"/>
> >
> > </xs:sequence>
> >
> >With a similar combination as in the g-app schema
> we'd
> >get:
> >
> > <xs:group
> >ref="naming:jndiEnvironmentRefsGroup"/>
> > <xs:element
> >ref="naming:message-destination" minOccurs="0"
> >maxOccurs="unbounded"/>
> >
> > <xs:element name="security-realm-name"
> >type="xs:string" minOccurs="0"/>
> >
> > <xs:any namespace="##other"
> >processContents="lax" minOccurs="0"
> >maxOccurs="unbounded"/>
> >
> > </xs:sequence>
> >
> >if the security-realm-name element was required
> >there'd be no problem, you could tell that the
> naming
> >elements are not part of the anys at the end.
> However
> >if it is missing, the naming elements could match
> the
> >explicit elements or the anys.
> >
> >I don't know how to get by this problem. xmlbeans
> has
> >a no-upa option which might let use use this
> schema,
> >but it's an invalid schema, so this is not
> completely
> >desirable. We could turn the entire schema into a
> >bunch of anys, but this sort of loses the point of
> >having a schema. We could make an incompatible
> change
> >to the schema, or we could special case the current
> >security namespace and effectively introduce
> another
> >element to hold other builders security info,
> >something like
> >
> > <xs:sequence minOccurs="0">
> > <xs:element
> name="security-realm-name"
> >type="xs:string"/>
> > <xs:choice>
> > <xs:element
> >ref="security:security" minOccurs="0"/>
> > <xs:element
> >ref="security:security-holder" minOccurs="0"/><!--
> >holds other peoples security element -->
> > </choice>
> > </xs:sequence>
> >
> >(I'm not sure this is a legal schema bit)
> >
> >I'm going to try out the noupa option first but I'm
> >hoping someone will come up with a generally better
> >approach.
> >
> >thanks
> >david jencks
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>
Re: Namespace-driven builders and the UPA rule
Posted by Gianny Damour <gi...@optusnet.com.au>.
Hi,
Is there a way to do this substitution of JACC implementation by
providing a substitutionGroup attribute to the security element?
This may be not be correct; yet, this could look like this:
<xs:complexType name="security">
<xs:sequence>
<xs:element ref="security:security" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="pluggable-security">
<xs:complexContent>
<xs:extension base="geronimo:security"/>
<xs:sequence>
<xs:element name="jacc-implementation"
type="xs:string"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element substitutionGroup="geronimo:security"
name="pluggable-security" type="geronimo:pluggable-security"/>
<xs:complexType name="applicationType">
<xs:sequence>
<xs:element ref="sys:environment"/>
<xs:element name="module" type="geronimo:moduleType"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="ext-module" type="geronimo:ext-moduleType"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="security" type="geronimo:security"
minOccurs="0"/>
<xs:element ref="sys:gbean" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<!--TODO application name should be settable using name-key in
the environment. Does this work? -->
<xs:attribute name="application-name" type="xs:string"
use="optional"/>
</xs:complexType>
I think that this approach is more verbose than the namespace-driven
approach; however, it is then easier to read the schema and understands
how to swap the JACC implementation.
Thanks,
Gianny
David Jencks wrote:
>For the pluggable jacc implementation (GERONIMO-1563)
>I've been working on making a basic namespace-driven
>builder framework. The code is simple and looks like
>it will work fine but..... there's a problem with the
>schema unique particle attribute rule, which basically
>says that in order for a schema to be valid each
>element can only be parsed in one way, and the way
>must be determined without looking forward or
>backwards or looking very hard at the context.
>
>OK. So, I wanted to make the geronimo security
>element namespace-driven, so if you used the current
>security-1.1 namespace you'd get our current impl, if
>you used something else you'd get that impl. We had
>
>...
> <xs:element name="ext-module"
>type="geronimo:ext-moduleType" minOccurs="0"
>maxOccurs="unbounded"/>
> <xs:element ref="security:security"
>minOccurs="0"/>
> <xs:element ref="sys:gbean" minOccurs="0"
>maxOccurs="unbounded"/>
> </xs:sequence>
>
>In order to make the security element variable, it
>needs to be <xs:any namespace="##other"
>minOccurs="0:/>
>
>Then in order to prevent the first gbean matching this
>if there's no security element I have to make the
>gbeans work through namespace driven builder too, and
>get
>...
> <xs:element name="ext-module"
>type="geronimo:ext-moduleType" minOccurs="0"
>maxOccurs="unbounded"/>
> <xs:any namespace="##other"
>processContents="lax" minOccurs="0"
>maxOccurs="unbounded"/>
> </xs:sequence>
>
>This works fine for the geronimo-application schema
>
>the problem comes with the web schemas (and perhaps
>the openejb schema, I haven't got that far yet). We
>now have
>
> <xs:group
>ref="naming:jndiEnvironmentRefsGroup"/>
> <xs:element
>ref="naming:message-destination" minOccurs="0"
>maxOccurs="unbounded"/>
>
> <xs:sequence minOccurs="0">
> <xs:element name="security-realm-name"
>type="xs:string"/>
> <xs:element ref="security:security"
>minOccurs="0"/>
> </xs:sequence>
>
> <xs:element ref="sys:gbean" minOccurs="0"
>maxOccurs="unbounded"/>
>
> </xs:sequence>
>
>With a similar combination as in the g-app schema we'd
>get:
>
> <xs:group
>ref="naming:jndiEnvironmentRefsGroup"/>
> <xs:element
>ref="naming:message-destination" minOccurs="0"
>maxOccurs="unbounded"/>
>
> <xs:element name="security-realm-name"
>type="xs:string" minOccurs="0"/>
>
> <xs:any namespace="##other"
>processContents="lax" minOccurs="0"
>maxOccurs="unbounded"/>
>
> </xs:sequence>
>
>if the security-realm-name element was required
>there'd be no problem, you could tell that the naming
>elements are not part of the anys at the end. However
>if it is missing, the naming elements could match the
>explicit elements or the anys.
>
>I don't know how to get by this problem. xmlbeans has
>a no-upa option which might let use use this schema,
>but it's an invalid schema, so this is not completely
>desirable. We could turn the entire schema into a
>bunch of anys, but this sort of loses the point of
>having a schema. We could make an incompatible change
>to the schema, or we could special case the current
>security namespace and effectively introduce another
>element to hold other builders security info,
>something like
>
> <xs:sequence minOccurs="0">
> <xs:element name="security-realm-name"
>type="xs:string"/>
> <xs:choice>
> <xs:element
>ref="security:security" minOccurs="0"/>
> <xs:element
>ref="security:security-holder" minOccurs="0"/><!--
>holds other peoples security element -->
> </choice>
> </xs:sequence>
>
>(I'm not sure this is a legal schema bit)
>
>I'm going to try out the noupa option first but I'm
>hoping someone will come up with a generally better
>approach.
>
>thanks
>david jencks
>
>
>
>
>
>
>
>
Re: Namespace-driven builders and the UPA rule
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
I don't really like listing "any" elements in the middle of our
schema. Then there's no way to tell what is valid or intended. Is
there any other possible way to make this work?
If not, I'd at least like to have a <security-provider> element that
holds the any so it's clear what the any is supposed to hold (and so
that all the following content doesn't also have to be "any").
But I would really prefer to do just about anything to avoid having
schemas that just have "any" in the middle. Now not only are you
required to use namespaces to make the file work at all, but also
there's no guidance at all as to what schemas or content are valid.
Thanks,
Aaron
On 6/17/06, David Jencks <da...@yahoo.com> wrote:
> The "noupa" approach seems to be working, although
> it's going to require changes to either or both of the
> m1 and m2 xmlbeans plugins... still investigating.
>
> thanks
> david jencks
>
>
> --- David Jencks <da...@yahoo.com> wrote:
>
> > For the pluggable jacc implementation
> > (GERONIMO-1563)
> > I've been working on making a basic namespace-driven
> > builder framework. The code is simple and looks
> > like
> > it will work fine but..... there's a problem with
> > the
> > schema unique particle attribute rule, which
> > basically
> > says that in order for a schema to be valid each
> > element can only be parsed in one way, and the way
> > must be determined without looking forward or
> > backwards or looking very hard at the context.
> >
> > OK. So, I wanted to make the geronimo security
> > element namespace-driven, so if you used the current
> > security-1.1 namespace you'd get our current impl,
> > if
> > you used something else you'd get that impl. We had
> >
> > ...
> > <xs:element name="ext-module"
> > type="geronimo:ext-moduleType" minOccurs="0"
> > maxOccurs="unbounded"/>
> > <xs:element ref="security:security"
> > minOccurs="0"/>
> > <xs:element ref="sys:gbean"
> > minOccurs="0"
> > maxOccurs="unbounded"/>
> > </xs:sequence>
> >
> > In order to make the security element variable, it
> > needs to be <xs:any namespace="##other"
> > minOccurs="0:/>
> >
> > Then in order to prevent the first gbean matching
> > this
> > if there's no security element I have to make the
> > gbeans work through namespace driven builder too,
> > and
> > get
> > ...
> > <xs:element name="ext-module"
> > type="geronimo:ext-moduleType" minOccurs="0"
> > maxOccurs="unbounded"/>
> > <xs:any namespace="##other"
> > processContents="lax" minOccurs="0"
> > maxOccurs="unbounded"/>
> > </xs:sequence>
> >
> > This works fine for the geronimo-application schema
> >
> > the problem comes with the web schemas (and perhaps
> > the openejb schema, I haven't got that far yet). We
> > now have
> >
> > <xs:group
> > ref="naming:jndiEnvironmentRefsGroup"/>
> > <xs:element
> > ref="naming:message-destination" minOccurs="0"
> > maxOccurs="unbounded"/>
> >
> > <xs:sequence minOccurs="0">
> > <xs:element
> > name="security-realm-name"
> > type="xs:string"/>
> > <xs:element ref="security:security"
> > minOccurs="0"/>
> > </xs:sequence>
> >
> > <xs:element ref="sys:gbean"
> > minOccurs="0"
> > maxOccurs="unbounded"/>
> >
> > </xs:sequence>
> >
> > With a similar combination as in the g-app schema
> > we'd
> > get:
> >
> > <xs:group
> > ref="naming:jndiEnvironmentRefsGroup"/>
> > <xs:element
> > ref="naming:message-destination" minOccurs="0"
> > maxOccurs="unbounded"/>
> >
> > <xs:element name="security-realm-name"
> > type="xs:string" minOccurs="0"/>
> >
> > <xs:any namespace="##other"
> > processContents="lax" minOccurs="0"
> > maxOccurs="unbounded"/>
> >
> > </xs:sequence>
> >
> > if the security-realm-name element was required
> > there'd be no problem, you could tell that the
> > naming
> > elements are not part of the anys at the end.
> > However
> > if it is missing, the naming elements could match
> > the
> > explicit elements or the anys.
> >
> > I don't know how to get by this problem. xmlbeans
> > has
> > a no-upa option which might let use use this schema,
> > but it's an invalid schema, so this is not
> > completely
> > desirable. We could turn the entire schema into a
> > bunch of anys, but this sort of loses the point of
> > having a schema. We could make an incompatible
> > change
> > to the schema, or we could special case the current
> > security namespace and effectively introduce another
> > element to hold other builders security info,
> > something like
> >
> > <xs:sequence minOccurs="0">
> > <xs:element
> > name="security-realm-name"
> > type="xs:string"/>
> > <xs:choice>
> > <xs:element
> > ref="security:security" minOccurs="0"/>
> > <xs:element
> > ref="security:security-holder" minOccurs="0"/><!--
> > holds other peoples security element -->
> > </choice>
> > </xs:sequence>
> >
> > (I'm not sure this is a legal schema bit)
> >
> > I'm going to try out the noupa option first but I'm
> > hoping someone will come up with a generally better
> > approach.
> >
> > thanks
> > david jencks
> >
> >
> >
> >
> >
>
>
Re: Namespace-driven builders and the UPA rule
Posted by David Jencks <da...@yahoo.com>.
The "noupa" approach seems to be working, although
it's going to require changes to either or both of the
m1 and m2 xmlbeans plugins... still investigating.
thanks
david jencks
--- David Jencks <da...@yahoo.com> wrote:
> For the pluggable jacc implementation
> (GERONIMO-1563)
> I've been working on making a basic namespace-driven
> builder framework. The code is simple and looks
> like
> it will work fine but..... there's a problem with
> the
> schema unique particle attribute rule, which
> basically
> says that in order for a schema to be valid each
> element can only be parsed in one way, and the way
> must be determined without looking forward or
> backwards or looking very hard at the context.
>
> OK. So, I wanted to make the geronimo security
> element namespace-driven, so if you used the current
> security-1.1 namespace you'd get our current impl,
> if
> you used something else you'd get that impl. We had
>
> ...
> <xs:element name="ext-module"
> type="geronimo:ext-moduleType" minOccurs="0"
> maxOccurs="unbounded"/>
> <xs:element ref="security:security"
> minOccurs="0"/>
> <xs:element ref="sys:gbean"
> minOccurs="0"
> maxOccurs="unbounded"/>
> </xs:sequence>
>
> In order to make the security element variable, it
> needs to be <xs:any namespace="##other"
> minOccurs="0:/>
>
> Then in order to prevent the first gbean matching
> this
> if there's no security element I have to make the
> gbeans work through namespace driven builder too,
> and
> get
> ...
> <xs:element name="ext-module"
> type="geronimo:ext-moduleType" minOccurs="0"
> maxOccurs="unbounded"/>
> <xs:any namespace="##other"
> processContents="lax" minOccurs="0"
> maxOccurs="unbounded"/>
> </xs:sequence>
>
> This works fine for the geronimo-application schema
>
> the problem comes with the web schemas (and perhaps
> the openejb schema, I haven't got that far yet). We
> now have
>
> <xs:group
> ref="naming:jndiEnvironmentRefsGroup"/>
> <xs:element
> ref="naming:message-destination" minOccurs="0"
> maxOccurs="unbounded"/>
>
> <xs:sequence minOccurs="0">
> <xs:element
> name="security-realm-name"
> type="xs:string"/>
> <xs:element ref="security:security"
> minOccurs="0"/>
> </xs:sequence>
>
> <xs:element ref="sys:gbean"
> minOccurs="0"
> maxOccurs="unbounded"/>
>
> </xs:sequence>
>
> With a similar combination as in the g-app schema
> we'd
> get:
>
> <xs:group
> ref="naming:jndiEnvironmentRefsGroup"/>
> <xs:element
> ref="naming:message-destination" minOccurs="0"
> maxOccurs="unbounded"/>
>
> <xs:element name="security-realm-name"
> type="xs:string" minOccurs="0"/>
>
> <xs:any namespace="##other"
> processContents="lax" minOccurs="0"
> maxOccurs="unbounded"/>
>
> </xs:sequence>
>
> if the security-realm-name element was required
> there'd be no problem, you could tell that the
> naming
> elements are not part of the anys at the end.
> However
> if it is missing, the naming elements could match
> the
> explicit elements or the anys.
>
> I don't know how to get by this problem. xmlbeans
> has
> a no-upa option which might let use use this schema,
> but it's an invalid schema, so this is not
> completely
> desirable. We could turn the entire schema into a
> bunch of anys, but this sort of loses the point of
> having a schema. We could make an incompatible
> change
> to the schema, or we could special case the current
> security namespace and effectively introduce another
> element to hold other builders security info,
> something like
>
> <xs:sequence minOccurs="0">
> <xs:element
> name="security-realm-name"
> type="xs:string"/>
> <xs:choice>
> <xs:element
> ref="security:security" minOccurs="0"/>
> <xs:element
> ref="security:security-holder" minOccurs="0"/><!--
> holds other peoples security element -->
> </choice>
> </xs:sequence>
>
> (I'm not sure this is a legal schema bit)
>
> I'm going to try out the noupa option first but I'm
> hoping someone will come up with a generally better
> approach.
>
> thanks
> david jencks
>
>
>
>
>