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] mustUnderstand attribute?


Title: RE: [xri-editors] mustUnderstand attribute?

We can’t think of any case where it makes sense. We can get the same “feature” by making a rule that says you’re only allowed to include elements in the XRID that are safely ignorable by the client.

 


From: Drummond Reed [mailto:drummond.reed@cordance.net]
Sent: Thursday, January 27, 2005 4:03 PM
To: 'Wachob, Gabe'; 'Davis, Peter'; Dave McAlpin; xri-editors@lists.oasis-open.org
Subject: RE: [xri-editors] mustUnderstand attribute?

 

Gabe, I agreed with you before, and now I do even more. After all, we did call it "Extensible Resource Identifier", so if we decide not to take the same approach to extensibility as SOAP, Atom, and XForms, we'd better have a pretty good reason.

 

Dave, can you see a good reason NOT to support the "mustUnderstand" design pattern?

 

=Drummond

 


From: Wachob, Gabe [mailto:gwachob@visa.com]
Sent: Thursday, January 27, 2005 1:45 PM
To: Davis, Peter; Dave McAlpin; xri-editors@lists.oasis-open.org
Subject: RE: [xri-editors] mustUnderstand attribute?

 

Actually, trusted res, for me, would NOT be considered mustUnderstand. If I, as a resolver, don't do trusted resolution, and I don't care about trust, then ignoring signatures when they appear, whether or not they are valid, should not cause me to fail.

 

BUT, the "mustUnderstand" design pattern is being used in SOAP, Atom (the replacement for RSS), XForms..

 

A good article on why to use mustUnderstand: http://www.xml.com/pub/a/2004/07/21/design.html - with some good background here as well: http://www.pacificspirit.com/blog/2004/07/27/dare%20versioning%20extensibility%20article%20comparison 

 

I'd note that by both accounts, we're doing a pretty good job w/r/t extensibility. The only glaring thing we are not doing is the mustUnderstand attribute. 

 

    -Gabe 

 


From: Davis, Peter [mailto:peter.davis@neustar.biz]
Sent: Thursday, January 27, 2005 1:09 PM
To: Wachob, Gabe; Dave McAlpin; xri-editors@lists.oasis-open.org
Subject: RE: [xri-editors] mustUnderstand attribute?

 

i can think see this for trustedres, personally.  note that this conversation occured in the WSS-tc osme time ago [1].  So gabe, i think i stand w/you on this topic.

--- peterd

[1] http://lists.oasis-open.org/archives/wss/200312/msg00021.html

-----Original Message-----
From: Wachob, Gabe [mailto:gwachob@visa.com]
Sent: Thu 1/27/2005 2:24 PM
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/members/leave_workgroup.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



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