[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] Thoughts about process for getting to cd02
Gabe, In your message below, you said: "To repeat, the only reasons I see for change at this point are: 1) we made a mistake in CD-01 that breaks functionality (errata), 2) we forgot to meet a requirement discussed *before* CD-01 (we agreed to do something in CD-01 but didn't) 3) we have a new/changed requirement since CD-01 that we absolutely need to meet for adoption (and this is a high bar - this is not "nice to haves" - the XRI-in-HTTP-URIs proposal might fall into this category)." You left two items out of your list that I believe are a major motivation for many of us contributing to these proposals: 4) We have discovered through implementation experience that there is a *significantly* simpler or better way of meeting the original and/or new requirements that we believe will *significantly* affect adoption. 5) We have recognized that there are aspects of our existing design/spec that would be all-but-impossible to change once adoption on a wide scale begins, and which if changed now we believe will *significantly* affect the future usability/scalability/extensibility of XRI infrastructure. The changes to XRI syntax that we underwent in going from 1.0 to 2.0 illustrate both of these criteria in action. To wit: * The change we made from our "internally-generated ABNF" in XRI 1.0 to an ABNF built completley on top of RFC 3986/3987 ABNF is an example of the first criteria. * The shift we made in XRI subsegment delimiter characters is an example of the second criteria. Of course, applying either of these criteria to justify a change requires judgement calls on the part of all of us on the TC in our roles as architects, designers, implementers, vendors, and customers of the specification. There is no black or white and only shades of gray. That is why there is bound to be major discussion about any change motivated by these criteria. (There certainly was in the move from XRI 1.0 to XRI 2.0 syntax.) However since I believe it is these two criteria that motivate a number of the revision proposals, I think it is very important that we discuss and acknowledge these reasons for a change. To be even specific, here is a list of the issues that I believe are significantly motivated by at least one of these two criteria: SYNTAX (http://wiki.oasis-open.org/xri/Xri2Cd02/SyntaxChanges) I2: ABNF/Allow Empty Path Segments I3: ABNF/Add HXRI and QXRI I4: XRI Normalization I5: XRI Length Limitations I6: Persistent XRI Best Practice RESOLUTION (http://wiki.oasis-open.org/xri/Xri2Cd02/ResolutionChanges) I1: Priority Attribute in XRIDs I3: XRI Redirect Handling I7: Refactoring for Normative Content I8: Refactoring for Local and Proxy Resolution I9: Refactoring $res Namespace I10: Refactoring XRID Schema (I don't think any of the current Metadata issues/proposals fall under these criteria.) =Drummond -----Original Message----- From: Wachob, Gabe [mailto:gwachob@visa.com] Sent: Tuesday, September 13, 2005 1:52 PM To: Lindelsee, Mike ; xri@lists.oasis-open.org Subject: RE: [xri] Thoughts about process for getting to cd02 As TC Co-chair, I want to echo and amplify what Mike is saying. We have, until now, been very consistent about following a process whereby we discuss issues (as driven by one or more requirements that have been documented either in the email list, a wiki, or the requirements doc), followed by agreement on the general approach to the solution, and proposals to address the issue and proposed specification additions or changes. It seems to me that many of the current change proposals are *not* driven by this process. Take for example "http://wiki.oasis-open.org/xri/Xri2Cd02/ReSolution/I8ResolutionRefactor " - following all the links there, I see no discussion of what the problem being addressed is, and we certainly haven't had any time to discuss how that problem might be addressed. All we are given is a change/addition proposal. There is no statement in the word document ("local-and-proxy-resolution-proposal-v1" that what is currently specific in CD-01 has any issues with providing the desired functionality. And furthermore, the desired functionality isn't even described outside of the change proposal to implement the desired functionality. Another example is I9 "Refactoring the $res namespace". What is the purpose of this change? We need to be much more disciplined in adopting these changes. The bar for changes should not be "is there a better way to do this than whats in CD-01", the bar should be "is the current way of doing things completely unworkable". And if you say the current way is totally unworkable, then we needs to rationalize why we thought it *was* workable in January of 2005 when we voted *affirmatively* on CD-01. I'm not hearing any of this sort of discussion. To repeat, the only reasons I see for change at this point are: 1) we made a mistake in CD-01 that breaks functionality (errata), 2) we forgot to meet a requirement discussed *before* CD-01 (we agreed to do something in CD-01 but didn't) 3) we have a new/changed requirement since CD-01 that we absolutely need to meet for adoption (and this is a high bar - this is not "nice to haves" - the XRI-in-HTTP-URIs proposal might fall into this category). It feels to me that CD-01 is pretty close to what (I had thought) we all wanted. If what the TC goals have changed, then we should explicitly discuss that change. If what we want has not changed, then we have to discuss *specifically* whats wrong or missing with CD-01 and how we can fix it, rather than simply proposing changes. -Gabe > -----Original Message----- > From: Lindelsee, Mike [mailto:mlindels@visa.com] > Sent: Tuesday, September 13, 2005 9:31 AM > To: xri@lists.oasis-open.org > Subject: [xri] Thoughts about process for getting to cd02 > > All, > > It's becoming clear to me that we've skipped a very important step in > going from cd01 to cd02. We really need to have all of the > requirements > for the various issues stated. I'm finding that every time we discuss > an issue, additional unstated requirements are uncovered. > While we can > review proposals, we can't understand their context or the feasability > of alternative solutions without understanding *all* of the > requirements > behind each issue. > > I don't belive that we can come to consensus on the majority of the > proposals without seeing the requirements for them. My preference is > that for each issue, requirements are posted and then discussed on the > list. That will let us agree, as a TC, as to which requirements are > ones that we want to tackle in cd02. After that agreement, > we can work > on proposals for fitting those agreed upon requirements into the XRI > architecture and specifications. > > While this might take some time and effort, it will > ultimately give us a > better spec -- and one that satisfies the needs of the TC members. > > Mike > > --------------------------------------------------------------------- > 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_workgr > oups.php > > --------------------------------------------------------------------- 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]