[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri-editors] mustUnderstand attribute?
The questions isn't about extensions in general. The question is about extensions that, if ignored, would end up with broken behavior on the part of the resolving clients. I haven't seen anything in XDI that falls into this category, though I haven't seen every proposal in detail. We could simply say "don't make extensions that do this". That's an entirely reasonable way to go. It might prove to be limiting in the future (or maybe not). Or we could propose the addition of mustUnderstand, probably stealing it directly from SOAP. But that's only if we agree *right now* that we need it. I don't want to have a long discussion about it, and I'm perfectly willing to accept a "we don't need it" quick decision. I think we *have* to do one of the two: "don't do this" or the "mustUnderstand" route. -Gabe > -----Original Message----- > From: Drummond Reed [mailto:drummond.reed@cordance.net] > Sent: Thursday, January 27, 2005 11:36 AM > To: Wachob, Gabe; 'Dave McAlpin'; xri-editors@lists.oasis-open.org > Subject: RE: [xri-editors] mustUnderstand attribute? > > Since we've already got a proposal for exactly the same thing > in the XDI TC, > it makes sense to me to do it here. How could we say we don't > anticipate > extensions when we've deliberately made XRI resolution extensible? > > =Drummond > > -----Original Message----- > From: Wachob, Gabe [mailto:gwachob@visa.com] > Sent: Thursday, January 27, 2005 11:25 AM > To: Dave McAlpin; xri-editors@lists.oasis-open.org > Subject: RE: [xri-editors] mustUnderstand attribute? > > Nothing now, by definition. We've defined all the required > semantics now > and compliant processors have to understand everything there is now. > > But I could easily see an example where we added a feature > that required > special processing by a resolver or proxy/etc for which a > failure should > be generated if such processing could not be accomodated. For example, > maybe there are policy statements (as extension elements in the XRID) > about how often an authority should be contacted (not more than once a > minute, for example) - and if you as a resolver don't understand that > policy statement, then you shouldn't even attempt to use the XRID and > should just throw up your hands and fail. > > For me, this is a judgement call - nothing will break today > if we don't > have it - I'm just trying to anticipate extensions, etc that > might come > back to bite us if we don't have a way of making them explicit. > > I'd be curious to hear other opinions. If this is something > others don't > see a need for, then we can probably pass. If people are designing > extensions with mandatory behaviors, they'll just have to find other > mechanisms to induce failure by resolvers if they resolvers don't > understand the extensions that require the mandatory new behavior. > > And of course, you may rightly believe that we'll never have such > extensions, or that we should strongly discourage them. I'd be open to > those opinions as well. > > -Gabe > > > -----Original Message----- > > From: Dave McAlpin [mailto:Dave.McAlpin@epok.net] > > Sent: Thursday, January 27, 2005 11:05 AM > > To: Wachob, Gabe; xri-editors@lists.oasis-open.org > > Subject: RE: [xri-editors] mustUnderstand attribute? > > > > I don't see the use case. What's an example of additional data in an > > XRID that _must_ be processed by the client? > > > > -----Original Message----- > > From: Wachob, Gabe [mailto:gwachob@visa.com] > > Sent: Thursday, January 27, 2005 9:54 AM > > To: xri-editors@lists.oasis-open.org > > Subject: [xri-editors] mustUnderstand attribute? > > > > Folks often talk about a mustUnderstand attribute as a way of > > controlling the use of extension elements in processing models > > surrounding XML documents. > > > > The idea is that a simple processor is allowed to ignore all > > elements it > > doesn't understand unless an element has a mustUnderstand="true" > > attribute. In this case, the processor, if it doesn't understand the > > element, must throw up its hands and give up. This allows > an extension > > author to create an extension that MUST be processed for correct > > functionality. Useful for security features, for example. > > > > Do we want to put something like this in XRI? Seems like it's > > a good way > > to future-proof current implementations and prevent breakage and > > headache down the road... > > > > -Gabe > > > > > > __________________________________________________ > > gwachob@visa.com > > Chief Systems Architect > > Technology Strategies and Standards > > Visa International > > Phone: +1.650.432.3696 Fax: +1.650.554.6817 > > > > > > 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_w > > orkgroup.php. > > > > > > -- > > No virus found in this incoming message. > > Checked by AVG Anti-Virus. > > Version: 7.0.302 / Virus Database: 265.8.1 - Release Date: 1/27/2005 > > > > > > 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. > > > > > > 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_workg > roup.php. > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]