[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Issue: overriding attributes
> That is not the only one we don't have. > > - the capability to declare patterns as a restriction of another and > let the processor check it. If the goal is to be able to valid W3C XML Schemas, then there is nothing needed here. > - multipart key That's true. But keys in XML Schema are pretty much a separate world from the rest of validation. > - runtime type substitution by using xsi:type. From the way I see it, this > is by far the biggest problem. This is an important, but I believe we can handle this by: - treating xsi:type as a normal attribute - using <value type="QName"> - using combine="choice" - using Murata-san's double indirection technique Suppose we have an element X with complex type A, where complex type A contains a single empty element Y, and a complex type B derived by extension from A adding an empty element Z. We could translate this into something like the following: <define name="X.element"> <element name="X"> <ref name="A.content.ref"/> </element> </define> <define name="A.content.ref"> <optional> <attribute name="xsi:type"> <value type="QName">A</value> </attribute> </optional> <ref name="A.content"/> </define> <define name="A.content"> <ref name="Y.element"/> </define> <define name="Y.element"> <element name="Y"> <empty/> </element> </define> <define name="B.content"> <ref name="A.content"/> <ref name="Z.element"/> </define> <define name="A.content.ref" combine="choice"> <attribute name="xsi:type"> <value type="QName">B</value> </attribute> <ref name="B.content"/> </define> <define name="Z.element"> <element name="Z"> <empty/> </element> </define> > - lax validation This is awkward, but I think it can be done. It's just a matter of defining a pattern along the lines of: <define name="lax"> <choice> <ref name="X.element"/> <ref name="Y.element"/> .. <element> <anyName> <except> <name>X</name> <name>Y</name> ... </except> </anyName> <ref name="lax"/> </element> </choice> </define> (or something like that, I'm not up on the details of lax validation) where X, Y, ... are the elements defined in the Schema. > ... and more. Such as? > > So as for your proposal, I am not actively proposing this. I just asking the question of whether it's a problem that it is awkward to implement this schema feature in RELAX NG. > 1. I don't think its widely used Have you looked at many schemas to verify this or are you just guessing? One widely used schema that uses this is the schema for schemas. James
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC