[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri-editors] further thinking on mustUnderstand
I see that we have three options: 1) Define a rule for any element that if an element with mustUnderstand attribute value of true appears of a child of a understood element, and the element with mustUnderstand=true is NOT understood, then the enclosing element must be considered to "not exist". For example, take the following: <XRIDescrpitor> <Authority> ... <other:ExtensionElement mustUnderstand="true">... </other:ExtensionElement> </Authority> <Service> ... </Service> </XRIDescriptor> If other:ExtensionElement is NOT understood, then the entire Authority element must be considered to be not understood and thus ignored. The Service element, however, *is* still valid. 2) We only define mustUnderstand on the top level children of <XRIDescriptor>. Thus, in the above example, a processor that didn't understand other:ExtensionElement would just ignore that particular element, but would be able to use the Authority element. This makes for simpler logic than #1. 3) We don't use mustUnderstand at all. We can actually get the same effect of mustUnderstand by requiring extensions to "wrap" other elements. So, for the example above: <XRIDescriptor> <other:SuperAuthority> <Authority> ... <other:ExtensionElement>...</other:ExtensionElement> </Authority> </other:SuperAuthority> <Service> ... </Service> </XRIDescriptors> This would have the same effect, using *only* a mustIgnore rule, as the #1 option. It may make the combining of extension elements quite complicated. Believe it or not, I'm leaning towards #3 because it provides a reasonable path forward, and requires almost no specification or coding effort to go forward. -Gabe
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]