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 <[EMAIL PROTECTED]> 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 > > > > >
