Re: [xri-editors] further thinking on mustUnderstand

[Peter C Davis <peter.davis@neustar.biz>]

I think we DO want to make some (potentially) normative declarations on how 
extensions to the schema should apply must[not]Understand.  I rather it be 
clear how extensions should impliment this to provide a consistant extension 
mechanism for others to work with.

one way to do this is to force extentions into theor own node in the heirarchy 
(eg <extension> element... which is somewhat commonplace, but not uniformly 
used).  this elemtn could carry must[not]Understand optional attribute, which 
would clarify things... not sure we want that placement contraint here... 
just a thought.

--- peterd

On Monday 07 February 2005 10:07 pm, Wachob, Gabe wrote:
> #3 means we don't specify anything.
>
> I just proposed one way that a extension author could write their
> extension if we didn't do mustUnderstand. There are other reasoanable
> ways too, I suppose.
>
> So, the short answer for your first question: we don't *enforce* the
> solution since there is no problem, currently.
>
> For your second question: This is better since we don't have to say
> anything about mustUnderstand semantics - we just have mustIgnore
> semantics. My proposal was just one way of simulating mustUnderstand in
> a mustIgnore-only environment.
>
> Third: we don't have to explain this solution since we don't require it
> and it doesn't have to be normative. We can simply put this issue to
> rest and not even discuss mustUnderstand at all. We can simply say "all
> unknown elements must be ignored"...
>
> 	-Gabe
>
> > -----Original Message-----
> > From: Drummond Reed [mailto:drummond.reed@cordance.net]
> > Sent: Monday, February 07, 2005 2:48 PM
> > To: 'Peter C Davis'; 'Dave McAlpin'
> > Cc: Wachob, Gabe; xri-editors@lists.oasis-open.org
> > Subject: RE: [xri-editors] further thinking on mustUnderstand
> >
> > I hate to be dumb, but how do we enforce such a proposal? Is the only
> > extension point then the XRIDescriptor element? Or do we just
> > do it with
> > normative text?
> >
> > Secondly, why is this better than the original situation of
> > just having a
> > global Must Ignore rule that any XRI resolver that doesn't
> > understand an
> > extension must ignore it?
> >
> > Lastly, is there clear precedence for this approach, that we
> > can point to so
> > we don't have to spend a bunch of energy and text explaining
> > our decision?
> >
> > Feel free to ring me to discuss if this is too much to go
> > over in text.
> >
> > =Drummond
> >
> >
> >
> > -----Original Message-----
> > From: Peter C Davis [mailto:peter.davis@neustar.biz]
> > Sent: Monday, February 07, 2005 11:29 AM
> > To: Dave McAlpin
> > Cc: Wachob, Gabe; Drummond Reed; xri-editors@lists.oasis-open.org
> > Subject: Re: [xri-editors] further thinking on mustUnderstand
> >
> > On Monday 07 February 2005 01:56 pm, Dave McAlpin wrote:
> > > 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?
> >
> > I am fine wrt option 3 as gabe described below i suppose...
> >
> > --- peterd
> >
> > > 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.
> >
> > 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/membe
> > rs/leave_workgroup.php.