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


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.
> 


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