[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? thanks =peterd 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 >> OASIS >> 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]