[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri-editors] Relative cross-references
Good point about CamelCase, Nat! Thats not a very i18n solution.
Spaces are of course legal, but get encoded as %20.
But I think we have concluded that we don't even have to address this issue normatively - its really an issue for the names that get registered under = (for example). In other words, its a namespace definition issue.
-Gabe
> -----Original Message-----
> From: Sakimura, Nat [mailto:n-sakimura@nri.co.jp]
> Sent: Wednesday, November 05, 2003 9:32 PM
> To: Dave McAlpin; Wachob, Gabe; Drummond Reed; Lindelsee, Mike;
> xri-editors@lists.oasis-open.org
> Cc: Veizades, John; Marc LeMaitre; jerry.kindall@epok.net
> Subject: RE: [xri-editors] Relative cross-references
>
>
> On the surface,
> > That doesn't solve 2396's objection, though, that if
> > white space is allowed, there are contexts in which it's
> > really hard to tell where the XRI begins and ends.
> seems quite reasonable. Indeed, it is so for most
> western languages. But in other languages where
> words and sentences are not delimited by spaces,
> e.g. Japanese, this argument becomes pretty weak.
>
> Earlier this thread, there was camel cap argument.
> e.g., =John Doe can be transcribed as =JohnDoe and
> the context is not lost. In many languages, however,
> there is no CAPs. Thus, camel cap notation is
> impossible and cannot be accepted.
> I neither like to overload the ".", but that's much better
> than camel cap.
>
> Then, I came to the question: "Why no spaces?"
>
> White space as the end of the identifier argument
> is gone as soon as we left ASCII world. The look alike
> problems are there for many other "visible" characters
> now. For the sake of uniformity, it might be better
> to state a normalization table for white spaces.
>
> Just my thought. It is not worth digging further,
> but just leaving the spec saying WSP is unrecommended
> than denied may be better. Editing should be pretty simple.
>
> Nat
>
> > -----Original Message-----
> > From: Dave McAlpin [mailto:dave.mcalpin@epokinc.com]
> > Sent: Thursday, November 06, 2003 12:51 AM
> > To: Sakimura, Nat; Wachob, Gabe; Drummond Reed; Lindelsee,
> > Mike; xri-editors@lists.oasis-open.org
> > Cc: Veizades, John; Marc LeMaitre; jerry.kindall@epok.net
> > Subject: RE: [xri-editors] Relative cross-references
> >
> > I was convinced by RFC2396, which says
> >
> > The space character is excluded because significant spaces
> > may disappear and insignificant spaces may be introduced when
> > URI are transcribed or typeset or subjected to the treatment
> > of word-processing programs. Whitespace is also used to
> > delimit URI in many contexts.
> >
> > It's true that whitespace isn't strictly disallowed in IRIs,
> > but it's not exactly encouraged either. The draft spec says
> >
> > Infrastructure accepting IRIs MAY also deal with the
> > printable characters in US-ASCII that are not allowed in
> > URIs, namely "<", ">", '"', Space, "{", "}", "|", "\", "^",
> > and "`", in step 3) above.
> >
> > i.e. they can be escaped when converting to a URI. However,
> > Section 6.1 of IRI advises whitespace in an IRI because it's
> > hard to distinguish "strong visual look-alikes", like tab and space.
> >
> > Some problems go away if we say whitespace is insignificant
> > for comparison.
> > That doesn't solve 2396's objection, though, that if
> > whitespace is allowed, there are contexts in which it's
> > really hard to tell where the XRI begins and ends.
> >
> > Dave
> >
> >
> > > -----Original Message-----
> > > From: Sakimura, Nat [mailto:n-sakimura@nri.co.jp]
> > > Sent: Wednesday, November 05, 2003 4:52 AM
> > > To: Wachob, Gabe; Drummond Reed; Lindelsee, Mike; Dave McAlpin;
> > > xri-editors@lists.oasis-open.org
> > > Cc: Veizades, John; Marc LeMaitre; jerry.kindall@epok.net
> > > Subject: RE: [xri-editors] Relative cross-references
> > >
> > >
> > > Sorry. I am lagging behind hopelessly.
> > >
> > > This thread made me look at the spec again made me ask this
> > question.
> > >
> > > "IRI allows Space. Why not XRI?"
> > >
> > > Trailing SP is not good, but in between seems OK to me,
> especially
> > > when not repeated.
> > >
> > > E.g. =Nat Sakimura can be ok as XRI, IMHO. Of course, it is
> > going to
> > > be escaped to =Nat%20Sakimura when it is handed over to URI
> > handling
> > > machines, but in writing, allowing a space seems more
> esthetically
> > > appealing. At least, XNS 1.0 implementations seem to allow such.
> > >
> > > Nat
> > >
> > > > -----Original Message-----
> > > > From: Wachob, Gabe [mailto:gwachob@visa.com]
> > > > Sent: Saturday, November 01, 2003 9:04 AM
> > > > To: 'Drummond Reed'; Lindelsee, Mike; 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
> > > >
> > > >
> > > > 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.
> > > >
> > > > 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_workgroup.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/members/l
> > eave_workgroup.php.
> >
> >
> >
> >
> >
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]