geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Mulder" <ammul...@alumni.princeton.edu>
Subject Re: Namespace-driven builders and the UPA rule
Date Sat, 17 Jun 2006 21:43:11 GMT
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 <david_jencks@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 <david_jencks@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
> >
> >
> >
> >
> >
>
>

Mime
View raw message