[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]