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


I'm fine with this.

-----Original Message-----
From: Wachob, Gabe [mailto:gwachob@visa.com] 
Sent: Friday, February 11, 2005 3:02 PM
To: Drummond Reed; Peter C Davis; Dave McAlpin;
xri-editors@lists.oasis-open.org
Subject: RE: [xri-editors] further thinking on mustUnderstand

Does anybody else have an opinion on this? If I don't hear anything
else, I'll include it (or something very much like it) in the text.

	-Gabe 

> -----Original Message-----
> From: Drummond Reed [mailto:drummond.reed@cordance.net] 
> Sent: Wednesday, February 09, 2005 9:21 AM
> To: Wachob, Gabe; 'Peter C Davis'; 'Dave McAlpin'; 
> xri-editors@lists.oasis-open.org
> Subject: RE: [xri-editors] further thinking on mustUnderstand
> 
> Gabe, this looks pretty good to me. It makes the intent quite clear.
> 
> =Drummond 
> 
> -----Original Message-----
> From: Wachob, Gabe [mailto:gwachob@visa.com] 
> Sent: Tuesday, February 08, 2005 10:01 AM
> To: Peter C Davis; Drummond Reed; Dave McAlpin;
> xri-editors@lists.oasis-open.org
> Subject: RE: [xri-editors] further thinking on mustUnderstand
> 
> Guys-
> 	I'm not sure we are actually closing in on a solution. It sounds
> like we agree and then disagree, etc. Here's my proposed text that we
> could put in the spec (quite rough). Do we all agree on this (or
> something close)?
> 	
> 	-Gabe
> 
> Proposed normative text:
> 
> All unknown extensions elements of an XRI Descriptor MUST be 
> ignorable.
> If an element is unknown, then any of its child elements, even if they
> are recognized elements by the consumer MUST also be ignored. An
> extension element therefore MUST NOT require interpretation or new
> behavior when processing other *known* elements in the XRI Descriptor,
> when those known elements appear in places defined by the XRI 
> Resolution
> schema. 
> 
> Extension specifications MAY simulate "mustUnderstand" behavior by
> applying a an "enclosure" pattern. Elements defined by the
> XRI-Resolution schema whose meaning or interpretation are to 
> be modified
> by extension elements can be wrapped in a extension container element,
> defined by the extension specification. This extension 
> container element
> would be in the same namespace as the extension elements which must be
> understood by the consumer of the XRI Descriptor. In doing this, the
> container and all the elements whose interpretation are 
> modified by the
> extension are contained in an element (the extension 
> container element)
> that is ignored by the consumer. In this way, if the consumer is
> ignorant of the extension, the consumer will be shielded from 
> even being
> aware that elements in the XRI-Resolution schema are 
> included, and thus
> they will be ignored. 
> 
> Example:
> 
> <XRIDescriptor>
>      <other:SuperAuthority>
>         <Authority>
>            ...
>            <other:ExtensionElement>...</other:ExtensionElement>
>         </Authority>
>      </other:SuperAuthority>
>       <Service>
>           ...
>       </Service>
> </XRIDescriptors>
> 
> In this example, the other:ExtensionElement modifies the 
> interpretation
> or processing rules for the Authority element. To preserve the correct
> interpretation of the Authority in this context, the Authority element
> is "wrapped" so that only consumers which understand elements in the
> "other" namespace (specifically other:SuperAuthority) will attempt to
> process the Authority element in this case. 
> 
> 
> 
> 
> > -----Original Message-----
> > From: Peter C Davis [mailto:peter.davis@neustar.biz] 
> > Sent: Tuesday, February 08, 2005 8:39 PM
> > To: Wachob, Gabe
> > Cc: Drummond Reed; Dave McAlpin; xri-editors@lists.oasis-open.org
> > Subject: Re: [xri-editors] further thinking on mustUnderstand
> > 
> > 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.
> > 
> 
> 
> 

-- 

Checked by AVG Anti-Virus.
Version: 7.0.305 / Virus Database: 265.8.7 - Release Date: 2/10/2005
 


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