OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri-editors message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [xri-editors] further thinking on mustUnderstand


After discussing this internally, I'm supporting Gabe's option 3. It
accomplishes what we're looking for while avoiding the problem of
inappropriate MustUnderstand attributes on immediate children of XRID.
It also has the nice effect of leaving the current schema intact. Can we
agree to close this issue?

Dave

-----Original Message-----
From: Wachob, Gabe [mailto:gwachob@visa.com] 
Sent: Monday, February 07, 2005 12:24 AM
To: Drummond Reed; Dave McAlpin; Peter C Davis;
xri-editors@lists.oasis-open.org
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 
          


To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/xri-editors/members/leave_w
orkgroup.php.


-- 
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.302 / Virus Database: 265.8.5 - Release Date: 2/3/2005
 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]