18 messages in org.oasis-open.lists.xri-editorsRE: [xri-editors] further thinking on...| From | Sent On | Attachments |
|---|---|---|
| Dave McAlpin | Feb 4, 2005 11:19 am | |
| Peter C Davis | Feb 4, 2005 11:39 am | |
| Dave McAlpin | Feb 4, 2005 11:43 am | |
| Peter C Davis | Feb 4, 2005 11:52 am | |
| Dave McAlpin | Feb 4, 2005 11:59 am | |
| Drummond Reed | Feb 4, 2005 3:32 pm | |
| Wachob, Gabe | Feb 6, 2005 2:23 pm | |
| Dave McAlpin | Feb 7, 2005 10:56 am | |
| Peter C Davis | Feb 7, 2005 11:28 am | |
| Drummond Reed | Feb 7, 2005 2:47 pm | |
| Wachob, Gabe | Feb 7, 2005 7:07 pm | |
| Dave McAlpin | Feb 7, 2005 7:22 pm | |
| Drummond Reed | Feb 7, 2005 7:51 pm | |
| Peter C Davis | Feb 8, 2005 5:45 am | |
| Wachob, Gabe | Feb 8, 2005 10:01 am | |
| Drummond Reed | Feb 9, 2005 9:20 am | |
| Wachob, Gabe | Feb 11, 2005 3:01 pm | |
| Dave McAlpin | Feb 11, 2005 3:03 pm |
| Subject: | RE: [xri-editors] further thinking on mustUnderstand | |
|---|---|---|
| From: | Drummond Reed (drum...@cordance.net) | |
| Date: | Feb 9, 2005 9:20:28 am | |
| List: | org.oasis-open.lists.xri-editors | |
Gabe, this looks pretty good to me. It makes the intent quite clear.
=Drummond
-----Original Message----- From: Wachob, Gabe [mailto:gwac...@visa.com] Sent: Tuesday, February 08, 2005 10:01 AM To: Peter C Davis; Drummond Reed; Dave McAlpin; xri-...@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:pete...@neustar.biz] Sent: Tuesday, February 08, 2005 8:39 PM To: Wachob, Gabe Cc: Drummond Reed; Dave McAlpin; xri-...@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:drum...@cordance.net] Sent: Monday, February 07, 2005 2:48 PM To: 'Peter C Davis'; 'Dave McAlpin' Cc: Wachob, Gabe; xri-...@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:pete...@neustar.biz] Sent: Monday, February 07, 2005 11:29 AM To: Dave McAlpin Cc: Wachob, Gabe; Drummond Reed; xri-...@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.