RE: [xri] Thoughts about process for getting to cd02

["Drummond Reed" <drummond.reed@cordance.net>]

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