OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xdi message

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

Subject: Re: [xdi] Re: [xri] Minutes:Joint XRI & XDI TC Telecon 10AM PT Thursday 2007-12-20

My main concern is that if an XRD(S) conformate to the present draft  
intentionally placed processing instructions about endpoint selection  
(for example), and a 'lite' resolver ignored these instructions (or  
did not understand them), then the publishers desired outcome may not  
be reached.

Did anyone capture notes on the issue that i can review, so that i  
can better understand the problem with the present XRDS?


On Dec 21, 2007, at 12:58 PM, Gabe Wachob wrote:

> Peter-
> 	The point here is to make a strict subset, not an incompatible
> version. That is, every XRDS/XRD-lite document is a legal XRDS/XRD  
> document
> and can be processed by a fully-semantically-enabled XRDS/XRD  
> processor. It
> wouldn't work the other way around, though (an XRD-lite processor  
> wouldn't
> or shouldn't be able to process an XRDS/XRD document with "beyond  
> lite"
> semantics and elements).
> 	Does this make you comfortable, or is there something about the
> disallowed elements that raises flags? I'm not quite understanding the
> practical issue you are raising.
> 	-Gabe
>> -----Original Message-----
>> From: Peter Davis [mailto:peter.davis@neustar.biz]
>> Sent: Friday, December 21, 2007 5:27 AM
>> To: Drummond Reed
>> Cc: xri@lists.oasis-open.org; xdi@lists.oasis-open.org
>> Subject: [xdi] Re: [xri] Minutes:Joint XRI & XDI TC Telecon 10AM PT
>> Thursday 2007-12-20
>> while i cannot dispute the utility of this proposal, i'd strongly
>> urge that the TC work towards a proposal which does not alter schema,
>> merely processing rules (as i think that is what i would imagine is
>> the challenge for some implementations).  Proposing a lite version
>> which breaks compatibility with the present 2.0-cd would be a huge
>> mistake.
>> =peterd
>> On Dec 20, 2007, at 6:22 PM, Drummond Reed wrote:
>>> Gabe explained that the idea of "XRDS lite" was to do a short spec
>>> about how
>>> to use a reduced set of the full XRDS element/attribute set that
>>> does not
>>> require processors to understand Redirect or Ref processing and
>>> full-scale
>>> SEP selection. Such a profile would including marking the outer
>>> XRDS element
>>> and/or each XRD element within it it with an attribute that
>>> indicated to
>>> processors that this XRDS or XRD uses only this limited set of
>>> semantics.
>>> John asked if a simple profile that could only be processed by  
>>> simple
>>> processors would invite problems in compatability with full XRDS
>>> processing.
>>> The feeling was that while that was true, it would not be much of a
>>> problem
>>> as long as the XRDS lite spec was a proper subset of XRDS, because
>>> then
>>> inverse would not be a problem, i.e., all full-scale XRDS
>>> processors will be
>>> able to handle any simple XRDS document or mixed simple/full XRDS
>>> document.
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail.  You may a link to this group and all your  
>> TCs in
>> at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/ 
>> my_workgroups.php

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