Donal K. Fellows wrote:
Michel Drescher wrote:
Yes I know. Both alternatives -- abstract types and substitutionGroups -- are functionally equivalent. So whichever fits best current tooling (the draft is in quite early stage, though) should be used in the extension. I have no preference, really.
On the other hand, the substitutionGroup technique requires you to define a default assignment function. I think there is no default assignment function that would be applicable here.
Actually, it doesn't. If the default is an abstract element, then people have to use the subtypes/elements instead. And it tools up correctly with at least one (Axis 1.3).
Yes, interesting alternative. Will explore this further.
Hence the example does not omit the SweepGroup element -- "SweepGroup" is an XML Schema group that does not render element start and end tags. Again, if tooling does not support that very well if at all, it is a matter of seconds to change that to a plain old contain er element.
Hmm, I'd be tempted to leave the type out then. Cuts confusion for us bears of little brain. :-)
CannotParseException - you are opting for using a container element (i.e. explicit start and end tag?)
The "Parameter" element's value is a XPath expression. So it may evaluate to an attribute's value or element value. If the assignment function is chosen wisely, then it yields strings that contain XML snippets. This way, you can sweep over EPRs...
I'd rather define the assignment values themselves to be XML chunks otherwise there's the whole question of how much quoting has to be done to assemble a string containing (in infoset space) <> characters.
Good point. Thought about this - which is the appropriate type? "xsd:anySimpleType"? Cheers, Michel -- Michel <dot> Drescher <at> uk <dot> fujitsu <dot> com Fujitsu Laboratories of Europe +44 20 8606 4834