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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri-editors message

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


Subject: RE: [xri-editors] Relative cross-references



Drummond-
	comments inline

> There already is one substitute character for whitespace, which is
> escaping it. But no one wants to type
> 
> 	=John%20Doe
> 
> And yet the fundamental problem with the "forced concatenation" of DNS
> and many other name services loses information.
> 
> 	=JohnDoe

I disagree, actually. I don't think you've lost any information in using MixedCase.

The change of case 100% preserves the word boundary. 

> Of course hyphens are legal in both DNS and XRI syntax, so you can use
> them as a fix.
> 
> 	=John-Doe

This is OK to me. I think its much less readable/intuitive than =JohnDoe, but I'm agreeable. BTW, HTML specifies using the + character as a replacement for space in querystrings. =John+Doe... again, not something you'd type into a ui, but something ui's do already today. 

> But you really can't attach strong semantic meaning to that 
> because some
> names natively include hyphens.
> 
> 	=Mary-Doe-Smith
> 
> Is that supposed to be "Mary-Doe Smith" or "Mary Doe-Smith"?

Thats a good point. Another reason to use MixedCase!

> After two months of thinking about this (literally, ever since the use
> cases for relative cross-references began to appear), I realized the
> most elegant solution to this problem was indeed relative
> cross-references, i.e., they are the clearest way to express the
> aggregation of the identifiers "John" and "Doe", as well as the
> aggregation of the identifiers "table", "of", and "contents", in the
> natural language order in which the would appear.
> 
> 	=(.John.Doe)
> 	+(table.of.contents)
> 	@(General.Motors)

This doesn't seem "elegant" to me - it may be functional, it may be simple to specify, but it looks ugly and I can't imagine a real user using it (since thats the use case we apparently are going with here). 

> 
> All the information is there, and it's unambiguous. 

How is this not unambiguous? I don't see how this addresses the problem that you now have to register Doe as a relative part of John -- that is, grouping all the people named John together and then each last name being resolved relative to that. And I don't understand how the concept that the John.Doe relative value changes the interpreation of the '.'

I get the feeling I'm missing something major here. 

> The only 
> thing it's
> not is super human-friendly. The final degree of subtlety (in the
> grouping of identifiers using parens) is, well, subtle.
> 
> But that's a problem that I think real world implementations 
> will solve
> in several ways (most directly, by UIs accepting all the combinations
> above and intelligently mapping them to the underlying XRI syntax).

Well, why couldn't they map them to =JohnDoe instead of =(John.Doe)? or maybe =John-Doe? 

> My final conclusion was that we didn't need anything different in XRI
> syntax than exactly what we have. All the necessary syntax to express
> the relationships between identifiers (in any language) are already
> there and as elegant as we can get them. As Einstein said, make it as
> simple as possible but no simpler.

Yes, thats a great way to do things. I'm just concerned that we're doing something which is totally unexpected given the current description of the syntax. And I'm not sure that it addresses the oddity of using "." as a hint to human readers that there are separate identifiers left and right of the separator. 

> 
> (If anyone can see a way to make this simpler still, please 
> stand up and
> shout ;-)

I still prefer case mixing (e.g. "=JohnDoe"). I don't think that just because the case is not important for comparison sake, it can't be used for cues to humans...

If we came up with a better description of what (John.Doe) meant, I spose I could be convinced, but it still seems like a very odd use of the syntax to me. 

	-Gabe

> 
> =Drummond 
> 
> 
> 
> 
> -----Original Message-----
> From: Lindelsee, Mike [mailto:mlindels@visa.com]
> Sent: Friday, October 31, 2003 2:59 PM
> To: 'Dave McAlpin'; Drummond Reed; Wachob, Gabe;
> xri-editors@lists.oasis-open.org
> Cc: Veizades, John; Marc LeMaitre; jerry.kindall@epok.net
> Subject: RE: [xri-editors] Relative cross-references
> 
> I also find dots as a substitute for whitespace to be confusing.  I
> think it is reasonable to have a substitute character for whitespace,
> but it probably shouldn't be a character that we already use.  I think
> overloading the semantics of the characters already used in XRIs will
> introduce unnecessary complication.
> 
> Mike
> 
> > -----Original Message-----
> > From: Dave McAlpin [mailto:dave.mcalpin@epokinc.com]
> > Sent: Friday, October 31, 2003 2:35 PM
> > To: 'Drummond Reed'; 'Wachob, Gabe'; 
> xri-editors@lists.oasis-open.org
> > Cc: 'Veizades, John'; 'Marc LeMaitre'; jerry.kindall@epok.net
> > Subject: RE: [xri-editors] Relative cross-references
> >
> >
> > I see. So the parens in the example xri:+(.table.of.contents)
> > are somewhat
> > comparable to quotes, and have the standard cross-reference 
> meaning of
> > "understand this as a single element".
> >
> > I'm still a little uncomfortable with dots as a substitute
> > for whitespace
> > here, but for some reason I'm fine with that concept in the =
> > namespace.
> > =John.Doe seems perfectly reasonable, partly because we're
> > used to seeing
> > John.Doe in mailto URIs, but also because I expect the =
> > namespace to be
> > flat and consequently I'm not tempted to read the dot as a point of
> > delegation. I don't think I have the same expectation of
> > flatness in the +
> > namespace, especially since we have the example of +flowers.rose.
> >
> > I'm still wondering if this is unnecessarily complicated for
> > the examples
> > section.
> >
> > Dave
> >
> > -----Original Message-----
> > From: Drummond Reed [mailto:drummond.reed@onename.com]
> > Sent: Friday, October 31, 2003 12:01 PM
> > To: Dave McAlpin; Wachob, Gabe; xri-editors@lists.oasis-open.org
> > Cc: Veizades, John; Marc LeMaitre; jerry.kindall@epok.net
> > Subject: RE: [xri-editors] Relative cross-references
> >
> > Funny you should ask, Dave. I was just about to use a relative
> > cross-reference to illustrate your answer to the last
> > question. As I've
> > studied the use of XRIs, esp. in the context for XDI, the issue of
> > "substituting for white space" has increased in importance.
> >
> > For example, if you want to reference the concept widely known in
> > English as "table of contents", you can't escape the reality
> > that it is
> > identified by 3 English words. No one knows it by the term
> > "contents" or
> > even "tablecontents". It is "table of contents".
> >
> > If you scrunch it down to "TableOfContents" or 
> "tableofcontents", you
> > lose information. You don't actually know the original three
> > words. And,
> > from a semantic mapping standpoint, you lose the absolutely critical
> > information that "table of contents" is actually linked to
> > the concepts
> > of "table" and "contents".
> >
> > So what's the best way to properly express this as an XRI?
> >
> >       xri:+(.table.of.contents)
> >
> > In other words, a relative XRI used as a cross-reference
> > because what it
> > does is link three separate concepts (table, of, and
> > contents) into one
> > concept.
> >
> > I've got several other use cases as well (some of which I
> > posted on the
> > discussion thread when I raised the whole issue of relative
> > cross-references) but I think this makes the point. I've got
> > to take off
> > for a meeting and will be offline for a few hours.
> >
> > =Drummond 
> >
> > -----Original Message-----
> > From: Dave McAlpin [mailto:dave.mcalpin@epokinc.com]
> > Sent: Friday, October 31, 2003 11:32 AM
> > To: 'Dave McAlpin'; Drummond Reed; 'Wachob, Gabe';
> > xri-editors@lists.oasis-open.org
> > Cc: 'Veizades, John'; Marc LeMaitre; jerry.kindall@epok.net
> > Subject: [xri-editors] Relative cross-references
> >
> > I see we're now allowing relative cross-references. I
> > remember we talked
> > about this and I guess we decided to allow them, but I'm not at all
> > clear
> > what they mean. Does someone have an actual use case in mind?
> >
> > Dave
> >
> >
> >
> >
> > 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-editors/membe
> rs/leave_w
> orkgroup.php.
> 
> 
> 
> 
> 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-editors/membe
rs/leave_w
orkgroup.php.


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