[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] Issue 1: Clarifying * Semantics
I could be mistaken, but I thought Drummond concluded by the end of that thread that making star and slash equivalent separators wasn't feasible, = and that star was always a second level separator, subordinate to slash. =20 Dave _____ =20 From: Victor Grey [mailto:victor@idcommons.org] Sent: Thu 7/8/2004 1:17 AM To: xri@lists.oasis-open.org Subject: Re: [xri] Issue 1: Clarifying * Semantics Wachob, Gabe wrote: > As to whether this is an aesthetic-only change, I'll let the initial=20 > proponents of this proposal speak up. I think its largely aesthetic I don't think anyone is claiming it's an aesthetic change. Au=20 contraire, it's somewhat uglier. In my mind the crucial point is the=20 philosophical/worldview imperative that Drummond wrote about on 6/11=20 (quoted below) - the need to highlight the distinction between a=20 hierarchical relationship and a peer relationship. -Victor Grey Drummond on 6/11: > First, just to make it clear, I agree with everyone that if the choice = > is > simply between the "readability" of the two examples given below, = i.e.: > > xri:@:3*:4*:5/:6*:7 > or > xri:@:3:4:5/:6:7 > > ...then of course it appears to be a no-brainer. The latter is more=20 > compact > and, as Peter says, "much easier to read". > > But therein lies the issue. What is "easier to read" depends on what=20 > you are > reading for. What I realized laying in bed at 4am this morning is that = > I am > reading for something entirely different. But to explain this requires > explaining the entire worldview behind this perspective, and entire > worldviews are not easy to explain, so please bear with me while I = try. > > In this second worldview, * would not be considered a "secondary=20 > hierarchy > character", but an "alternative hierarchy character" on an equal=20 > footing > with slash. > > I can just hear Dave screaming right now, "What does Drummond mean, = 'an > "alternative hierarchy character" on an equal footing with slash'?? = How > could there be such a thing? Slash is THE 2396 hierarchy character! It > defines 2396 segments. The only option we have is to define = subsegments > within slash segments!" > > But this is exactly what I mean about two entirely different=20 > worldviews. In > the 2396 worldview the world is purely hierarchical. There is only=20 > slash > because there is only hierarchy. > > It's pretty ironic, then, that URIs based on 2396 are the very basis=20 > of the > World Wide Web, which is the very opposite of hierarchy. It's a=20 > peer-to-peer > web. Any page can link to any page. > > Laying in bed at 4am, I did the following thought experiment, "Using > conventional URIs, is there any way you can address the LINK between=20 > two web > pages?" In other words, not the URI of Page A or the URI of Page B,=20 > but the > LINK from Page A to Page B. Literally, the A tag present in the HTML=20 > of Page > A that links to Page B. > > There is certainly no standard way, at least that I know of. So I=20 > started > thinking through how you would do it. If Page A was expressed as=20 > XHTML, then > the actual node of the XHTML document that contains the link to Page B = > would > at least be addressable using an XPath expression under the URI of=20 > Page A. > So you could have something like: > > http://www.example.com/Page-A#Xpath-to-A-tag-linking-Page-B > > Of course, there is no spec for doing this that I am aware of. However = > it > wouldn't be hard to construct one. Since you know the link is in an A=20 > tag, > you'd just need a standard XPath query that says, "Give me the A tag=20 > whose > HREF attribute equals the following value" and then supply the target=20 > URI as > a paremeter. Say this query was called "Xpath-A-ref". Then any site=20 > that > supported this query could resolve a URI that looked like the=20 > following: > > http://www.example.com/Page-A?Xpath-A-ref <http://www.example.com/Page-A?Xpath-A-ref&HREF=3D> &HREF=3D"http://www.site.com/ > Page-B" > > Such an address would actually let you address Page B in the context=20 > of Page > A. It lets you construct a path ACROSS pages, not just DOWN the DNS=20 > tree and > local file path hierarchy to a specific page. > > Why would you want to be able to address across Web pages? If you=20 > wanted to > be able to follow the path of who is linked to who. It lets you test > assertions about relationships between pages. If the address above=20 > resolves, > it tells you Page A is linked to Page B. If it doesn't, they aren't. > > Now, imagine if there was: a) a standard URI syntax character that=20 > equates > to the link query operation "?x-path-A-ref" above, and b) a standard=20 > way in > URI syntax to nest one URI inside another. Let's say the standard link = > query > character was * and the nesting syntax was to enclose the nested URI = in > parentheses. Then the URI above could be expressed much more compactly = > and > readably as: > > http://www.example.com/Page-A*(http://www.site.com/Page-B) > > Now let's take one more step. Say that the author of Page A had his=20 > own name > for Page B inside the HREF tag that points to=20 > "http://www.site.com/Page-B";. > Say this name was "Glockenspiel". This is really a relative identifier = > for > Page B, since it's relative to the Web page=20 > http://www.example.com/Page-A. > But in the context of this Web page, it's very likely to be unique,=20 > since > the author of Page A is unlikely to create two outgoing links to=20 > different > resources on the same Web page and label both the A tags identically. > > In this case there is a second way to address the link between Page A=20 > and > Page B using this relative identifier. This would look like: > > http://www.example.com/Page-A*(Glockenspiel) > > I know this example has been quite extensive, but as you can see, the=20 > point > is that in this alternative worldview - this Web-based worldview - > peer-to-peer linking relationships have an equal status with=20 > hierarchical > relationships. Neither is "good" or "bad". Neither is "primary" or > "secondary". They are simply equally valid. Like Cartesian and radian > coordinate systems, they both let you address any point on a plane -=20 > it's > just that each one can be much more appropriate for certain tasks. > > It follows then that in this worldview, the primary failing of 2396=20 > syntax > is that it does not accommodate the peer-to-peer linking worldview. It = > only > accommodates the hierarchical worldview. It has no syntax for=20 > addressing > link relationships, nor for nesting identifiers for this purpose = (i.e., > cross-references). In syntactic terms, it has only /, and no * nor (). > > Those of you who know me know why I am so passionate about this=20 > subject. To > get from the Web to the Dataweb, we must be able to express the links > between data and the links between data sharing authorities. Suddenly=20 > it is > as important (if not more important) to be able to address the source=20 > of > authority and permission in a data sharing relationship as it is to be = > able > to address the data being shared. > > For example, look at the following sample XRI: > > xri:xri-A/(xri-B)*(/($contract)/this-contract/($v1))*(/(+email)/work/ > ($v2)) > > (Note that the values "xri-A" and "xri-B" are placeholders for the=20 > actual > XRIs for Authority A and Authority B, and "$contract" is the proposed=20 > XRI > service dictionary identifier for XDI link contracts.) This is from a=20 > thread > about potential XDI contract addressing available at > http://wiki.idcommons.net/moin.cgi/DataSharing#head > -0bd543034533c5641c0beacf > 65be418a7a9c7fc5. > > Although this particular example is in the context of XDI (and uses=20 > only a > proposed addressing syntax in that context), what I believe it=20 > illustrates > is the tremendous importance, in that context, of link relationships.=20 > For > example, this XRI expresses that authority A's relationship with=20 > authority B > (xri-A/xri-B) is linked to a link contract from authority A > (/($contract)/this-contract/($v1)) which is linked to a specific item=20 > of > data from authority A (/(+email)/work/($v2)). > > So, in conclusion: > > * In the hierarchical-only worldview, / reigns supreme, and therefore=20 > the > distinction between * and : as "secondary hierarchy" characters = appears > relatively minor. > > * In the combined hierarchy-and-peer-to-peer-link worldviews, / and *=20 > are > equally important and equally valid first-level delimiters. / is used=20 > to > express for hierarchical relationships between resources and * is used = > to > express peer-to-peer linking relationships between resources. In this > worldview, both "/:" and "*:" would be equally valid, as colon would=20 > always > be used as the prefix for a persistent identifier. > > I believe this worldview is not unique to XDI. Although XDI=20 > architecture is > fundamentally based on the ability to express links between resources, = > and > it uses XRIs for this purpose, I believe that establishing the=20 > syntactic > "equal footing" of * and / for the purpose of enabling the expression=20 > of > peer-to-peer linking vs. hierarchical relationships could apply to = many > other uses of XRI beyond the scope of XDI. > > I hope this explanation helps bridge the gap between these two=20 > worldviews. > > =3DDrummond 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/members/leave_workgroup.= php . ------=_NextPart_000_0047_01C46480.AA1438E0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dus-ascii"> <TITLE>Message</TITLE> <META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR></HEAD> <BODY> <DIV><FONT face=3DTahoma color=3D#0000ff size=3D2><SPAN=20 class=3D686231306-08072004>Drummond's mail of 6/11 spurred a flurry = of XDI=20 related mail.</SPAN></FONT></DIV> <DIV><FONT face=3DTahoma color=3D#0000ff size=3D2><SPAN=20 class=3D686231306-08072004></SPAN></FONT><FONT face=3DTahoma = color=3D#0000ff=20 size=3D2><SPAN class=3D686231306-08072004></SPAN></FONT> </DIV> <DIV><FONT face=3DTahoma color=3D#0000ff size=3D2><SPAN = class=3D686231306-08072004>From=20 my recollection, it was determined that while it's imperative that this = (and=20 other) relationship data is addressable, duplicating it = into the=20 identifier is inappropriate.</SPAN></FONT></DIV> <DIV><FONT face=3DTahoma color=3D#0000ff size=3D2><SPAN=20 class=3D686231306-08072004></SPAN></FONT><FONT face=3DTahoma = color=3D#0000ff=20 size=3D2><SPAN class=3D686231306-08072004></SPAN></FONT> </DIV> <DIV><FONT face=3DTahoma color=3D#0000ff size=3D2><SPAN = class=3D686231306-08072004>The=20 conversations never made their way back to the XRI lists because current = XRI=20 syntax supports addressing this vital relationship=20 information.</SPAN></FONT></DIV> <DIV><FONT face=3DTahoma color=3D#0000ff size=3D2><SPAN=20 class=3D686231306-08072004></SPAN></FONT> </DIV> <DIV><FONT face=3DTahoma color=3D#0000ff size=3D2><SPAN = class=3D686231306-08072004>I'd=20 be happy to continue the discussions on the XDI lists if necessary, but = the XDI=20 group is far from recommending a change to the XRI = syntax.</SPAN></FONT></DIV> <DIV><FONT face=3DTahoma color=3D#0000ff size=3D2><SPAN=20 class=3D686231306-08072004></SPAN></FONT><FONT face=3DTahoma = color=3D#0000ff=20 size=3D2><SPAN class=3D686231306-08072004></SPAN></FONT> </DIV> <DIV><FONT face=3DTahoma color=3D#0000ff size=3D2><SPAN = class=3D686231306-08072004>In=20 fact, from an XRI perspective, any group that recommends = changing XRI=20 syntax to support the storage of data in identifiers is likely = to meet=20 with some pretty serious opposition.</SPAN></FONT></DIV> <DIV><FONT face=3DTahoma color=3D#0000ff size=3D2><SPAN=20 class=3D686231306-08072004></SPAN></FONT> </DIV> <DIV><FONT face=3DTahoma color=3D#0000ff size=3D2><SPAN=20 class=3D686231306-08072004>=3DLoren</SPAN></FONT></DIV> <DIV><FONT face=3DTahoma color=3D#0000ff size=3D2><SPAN=20 class=3D686231306-08072004></SPAN></FONT> </DIV> <DIV></DIV> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr = align=3Dleft><FONT face=3DTahoma=20 size=3D2>-----Original Message-----<BR><B>From:</B> Dave McAlpin=20 [mailto:Dave.McAlpin@epok.net] <BR><B>Sent:</B> Wednesday, July 07, 2004 = 10:22=20 PM<BR><B>To:</B> Victor Grey; = xri@lists.oasis-open.org<BR><B>Subject:</B> RE:=20 [xri] Issue 1: Clarifying * Semantics<BR><BR></FONT></DIV> <DIV id=3DidOWAReplyText44832 dir=3Dltr> <DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>I could be = mistaken, but I=20 thought Drummond concluded by the end of that thread that making star = and slash=20 equivalent separators wasn't feasible, and that star was always a second = level=20 separator, subordinate to slash.</FONT></DIV> <DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT> </DIV> <DIV dir=3Dltr><FONT face=3DArial size=3D2>Dave</FONT></DIV></DIV> <DIV dir=3Dltr><BR> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> Victor Grey=20 [mailto:victor@idcommons.org]<BR><B>Sent:</B> Thu 7/8/2004 1:17 = AM<BR><B>To:</B>=20 xri@lists.oasis-open.org<BR><B>Subject:</B> Re: [xri] Issue 1: = Clarifying *=20 Semantics<BR></FONT><BR></DIV> <DIV> <P><FONT size=3D2>Wachob, Gabe wrote:<BR>> As to whether this is an=20 aesthetic-only change, I'll let the initial <BR>> proponents of = this=20 proposal speak up. I think its largely aesthetic<BR><BR>I don't think = anyone is=20 claiming it's an aesthetic change. Au <BR>contraire, it's somewhat = uglier.=20 In my mind the crucial point is the <BR>philosophical/worldview = imperative=20 that Drummond wrote about on 6/11 <BR>(quoted below) - the need to=20 highlight the distinction between a <BR>hierarchical relationship = and a=20 peer relationship.<BR><BR>-Victor Grey<BR><BR>Drummond on 6/11:<BR>> = First,=20 just to make it clear, I agree with everyone that if the = choice <BR>>=20 is<BR>> simply between the "readability" of the two examples given = below,=20 i.e.:<BR>><BR>> xri:@:3*:4*:5/:6*:7<BR>> or<BR>>=20 xri:@:3:4:5/:6:7<BR>><BR>> ...then of course it appears to be a=20 no-brainer. The latter is more <BR>> compact<BR>> and, as = Peter says,=20 "much easier to read".<BR>><BR>> But therein lies the issue. What = is=20 "easier to read" depends on what <BR>> you are<BR>> reading = for. What=20 I realized laying in bed at 4am this morning is that <BR>> I = am<BR>>=20 reading for something entirely different. But to explain this = requires<BR>>=20 explaining the entire worldview behind this perspective, and = entire<BR>>=20 worldviews are not easy to explain, so please bear with me while I=20 try.<BR>><BR>> In this second worldview, * would not be considered = a=20 "secondary <BR>> hierarchy<BR>> character", but an = "alternative=20 hierarchy character" on an equal <BR>> footing<BR>> with=20 slash.<BR>><BR>> I can just hear Dave screaming right now, "What = does=20 Drummond mean, 'an<BR>> "alternative hierarchy character" on an equal = footing=20 with slash'?? How<BR>> could there be such a thing? Slash is THE 2396 = hierarchy character! It<BR>> defines 2396 segments. The only option = we have=20 is to define subsegments<BR>> within slash segments!"<BR>><BR>> = But=20 this is exactly what I mean about two entirely different <BR>>=20 worldviews. In<BR>> the 2396 worldview the world is purely = hierarchical.=20 There is only <BR>> slash<BR>> because there is only=20 hierarchy.<BR>><BR>> It's pretty ironic, then, that URIs based on = 2396 are=20 the very basis <BR>> of the<BR>> World Wide Web, which is the = very=20 opposite of hierarchy. It's a <BR>> peer-to-peer<BR>> web. = Any page=20 can link to any page.<BR>><BR>> Laying in bed at 4am, I did the = following=20 thought experiment, "Using<BR>> conventional URIs, is there any way = you can=20 address the LINK between <BR>> two web<BR>> pages?" In other = words,=20 not the URI of Page A or the URI of Page B, <BR>> but = the<BR>> LINK=20 from Page A to Page B. Literally, the A tag present in the = HTML <BR>> of=20 Page<BR>> A that links to Page B.<BR>><BR>> There is certainly = no=20 standard way, at least that I know of. So I <BR>> = started<BR>>=20 thinking through how you would do it. If Page A was expressed = as <BR>>=20 XHTML, then<BR>> the actual node of the XHTML document that contains = the link=20 to Page B <BR>> would<BR>> at least be addressable using an = XPath=20 expression under the URI of <BR>> Page A.<BR>> So you could = have=20 something like:<BR>><BR>> <A=20 href=3D"http://www.example.com/Page-A#Xpath-to-A-tag-linking-Page-B";>http= ://www.example.com/Page-A#Xpath-to-A-tag-linking-Page-B</A><BR>><BR>&g= t;=20 Of course, there is no spec for doing this that I am aware of.=20 However <BR>> it<BR>> wouldn't be hard to construct one. = Since you=20 know the link is in an A <BR>> tag,<BR>> you'd just need a = standard=20 XPath query that says, "Give me the A tag <BR>> whose<BR>> = HREF=20 attribute equals the following value" and then supply the = target <BR>>=20 URI as<BR>> a paremeter. Say this query was called "Xpath-A-ref". = Then any=20 site <BR>> that<BR>> supported this query could resolve a URI = that=20 looked like the <BR>> following:<BR>><BR>> <A=20 href=3D"http://www.example.com/Page-A?Xpath-A-ref&HREF=3D";>http://www= .example.com/Page-A?Xpath-A-ref&HREF=3D</A>"<A=20 href=3D"http://www.site.com/";>http://www.site.com/</A><BR>>=20 Page-B"<BR>><BR>> Such an address would actually let you address = Page B in=20 the context <BR>> of Page<BR>> A. It lets you construct a = path ACROSS=20 pages, not just DOWN the DNS <BR>> tree and<BR>> local file = path=20 hierarchy to a specific page.<BR>><BR>> Why would you want to be = able to=20 address across Web pages? If you <BR>> wanted to<BR>> be able = to=20 follow the path of who is linked to who. It lets you test<BR>> = assertions=20 about relationships between pages. If the address above <BR>>=20 resolves,<BR>> it tells you Page A is linked to Page B. If it = doesn't, they=20 aren't.<BR>><BR>> Now, imagine if there was: a) a standard URI = syntax=20 character that <BR>> equates<BR>> to the link query operation = "?x-path-A-ref" above, and b) a standard <BR>> way in<BR>> = URI syntax=20 to nest one URI inside another. Let's say the standard = link <BR>>=20 query<BR>> character was * and the nesting syntax was to enclose the = nested=20 URI in<BR>> parentheses. Then the URI above could be expressed much = more=20 compactly <BR>> and<BR>> readably as:<BR>><BR>>=20 <A=20 href=3D"http://www.example.com/Page-A*(http://www.site.com/Page-B";>http:/= /www.example.com/Page-A*(http://www.site.com/Page-B</A>)<BR>><BR>> = Now let's take one more step. Say that the author of Page A had=20 his <BR>> own name<BR>> for Page B inside the HREF tag that = points=20 to <BR>> "<A=20 href=3D"http://www.site.com/Page-B";>http://www.site.com/Page-B</A>".<BR>&= gt; Say=20 this name was "Glockenspiel". This is really a relative = identifier <BR>>=20 for<BR>> Page B, since it's relative to the Web page <BR>> <A = href=3D"http://www.example.com/Page-A";>http://www.example.com/Page-A</A>.= <BR>>=20 But in the context of this Web page, it's very likely to be=20 unique, <BR>> since<BR>> the author of Page A is unlikely to = create=20 two outgoing links to <BR>> different<BR>> resources on the = same Web=20 page and label both the A tags identically.<BR>><BR>> In this case = there=20 is a second way to address the link between Page A <BR>> = and<BR>>=20 Page B using this relative identifier. This would look = like:<BR>><BR>>=20 <A=20 href=3D"http://www.example.com/Page-A*(Glockenspiel">http://www.example.c= om/Page-A*(Glockenspiel</A>)<BR>><BR>>=20 I know this example has been quite extensive, but as you can see,=20 the <BR>> point<BR>> is that in this alternative worldview - = this=20 Web-based worldview -<BR>> peer-to-peer linking relationships have an = equal=20 status with <BR>> hierarchical<BR>> relationships. Neither is = "good"=20 or "bad". Neither is "primary" or<BR>> "secondary". They are simply = equally=20 valid. Like Cartesian and radian<BR>> coordinate systems, they both = let you=20 address any point on a plane - <BR>> it's<BR>> just that each = one can=20 be much more appropriate for certain tasks.<BR>><BR>> It follows = then that=20 in this worldview, the primary failing of 2396 <BR>> = syntax<BR>> is=20 that it does not accommodate the peer-to-peer linking worldview.=20 It <BR>> only<BR>> accommodates the hierarchical worldview. = It has no=20 syntax for <BR>> addressing<BR>> link relationships, nor for = nesting=20 identifiers for this purpose (i.e.,<BR>> cross-references). In = syntactic=20 terms, it has only /, and no * nor ().<BR>><BR>> Those of you who = know me=20 know why I am so passionate about this <BR>> subject. To<BR>> = get=20 from the Web to the Dataweb, we must be able to express the = links<BR>>=20 between data and the links between data sharing authorities.=20 Suddenly <BR>> it is<BR>> as important (if not more = important) to be=20 able to address the source <BR>> of<BR>> authority and = permission in=20 a data sharing relationship as it is to be <BR>> able<BR>> to = address=20 the data being shared.<BR>><BR>> For example, look at the = following sample=20 XRI:<BR>><BR>>=20 xri:xri-A/(xri-B)*(/($contract)/this-contract/($v1))*(/(+email)/work/<BR>= >=20 ($v2))<BR>><BR>> (Note that the values "xri-A" and "xri-B" are=20 placeholders for the <BR>> actual<BR>> XRIs for Authority A = and=20 Authority B, and "$contract" is the proposed <BR>> XRI<BR>> = service=20 dictionary identifier for XDI link contracts.) This is from = a <BR>>=20 thread<BR>> about potential XDI contract addressing available = at<BR>> <A=20 href=3D"http://wiki.idcommons.net/moin.cgi/DataSharing#head";>http://wiki.= idcommons.net/moin.cgi/DataSharing#head</A><BR>>=20 -0bd543034533c5641c0beacf<BR>> 65be418a7a9c7fc5.<BR>><BR>> = Although=20 this particular example is in the context of XDI (and uses <BR>> = only=20 a<BR>> proposed addressing syntax in that context), what I believe=20 it <BR>> illustrates<BR>> is the tremendous importance, in = that=20 context, of link relationships. <BR>> For<BR>> example, this = XRI=20 expresses that authority A's relationship with <BR>> authority = B<BR>>=20 (xri-A/xri-B) is linked to a link contract from authority A<BR>>=20 (/($contract)/this-contract/($v1)) which is linked to a specific=20 item <BR>> of<BR>> data from authority A=20 (/(+email)/work/($v2)).<BR>><BR>> So, in = conclusion:<BR>><BR>> * In=20 the hierarchical-only worldview, / reigns supreme, and = therefore <BR>>=20 the<BR>> distinction between * and : as "secondary hierarchy" = characters=20 appears<BR>> relatively minor.<BR>><BR>> * In the combined=20 hierarchy-and-peer-to-peer-link worldviews, / and * <BR>> = are<BR>>=20 equally important and equally valid first-level delimiters. / is=20 used <BR>> to<BR>> express for hierarchical relationships = between=20 resources and * is used <BR>> to<BR>> express peer-to-peer = linking=20 relationships between resources. In this<BR>> worldview, both "/:" = and "*:"=20 would be equally valid, as colon would <BR>> always<BR>> be = used as=20 the prefix for a persistent identifier.<BR>><BR>> I believe this = worldview=20 is not unique to XDI. Although XDI <BR>> architecture is<BR>> = fundamentally based on the ability to express links between=20 resources, <BR>> and<BR>> it uses XRIs for this purpose, I = believe=20 that establishing the <BR>> syntactic<BR>> "equal footing" of = * and /=20 for the purpose of enabling the expression <BR>> of<BR>> = peer-to-peer=20 linking vs. hierarchical relationships could apply to many<BR>> other = uses of=20 XRI beyond the scope of XDI.<BR>><BR>> I hope this explanation = helps=20 bridge the gap between these two <BR>> = worldviews.<BR>><BR>>=20 =3DDrummond<BR><BR><BR>To unsubscribe from this mailing list (and be = removed from=20 the roster of the OASIS TC), go to <A=20 href=3D"http://www.oasis-open.org/apps/org/workgroup/xri/members/leave_wo= rkgroup.php">http://www.oasis-open.org/apps/org/workgroup/xri/members/lea= ve_workgroup.php</A>.<BR><BR></FONT></P></DIV></BODY></HTML> ------=_NextPart_000_0047_01C46480.AA1438E0--
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]