[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] Proposal for XRI Syntax 2.1 to treat all delimiters as signficant
Les, I would say that in addition to the two
you list, I would state a third more general requirement: * Make XRI 2.1 syntax as simple and
regular as possible, because we cannot anticipate all future use cases for XRI
syntax, and a simple, regular syntax will better serve developers and infrastructures
that want to put XRI to uses we cannot yet anticipate. In hindsight, XRI 2.0 syntax had a fairly
large number of special exceptions to it, and thus this requirement serves as
the motivation to remove some of those exceptions, such as the double usage of
! as both a GCS and LCS character. =Drummond From: Chasen, Les
[mailto:les.chasen@neustar.biz] One thing that will help me is a review of
the requirements we are trying to meet. I think I have heard two: * Officially remove the first optional *
between the GCS and authority * Make cross references easier for humans. Is that it? From: Schleiff, Marty
[mailto:marty.schleiff@boeing.com] I've reserve 11:00-1:00 PT today
(Wednesday) for a discussion. Anyone who wants to join us can do so at
1-866-648-8101 - 3188834#. Marty.Schleiff@boeing.com;
CISSP From: Drummond
Reed [mailto:drummond.reed@cordance.net] Marty, I’m tied up until 11AM PT
tomorrow, but if we could talk sometime between 11AM and 1PM PT tomorrow, that
would be great. I’ve no idea if Les or Wil or anyone else is available at
that time, but I’ll check with Les in the morning, and whatever time we
choose we’ll publish a telecon number to the TC list so anyone else who
is available can join us. Also, you mention being available for 90
minutes following the TC call on Thursday – do you mean from 10AM to
11:30AM PT? If so, the TC call begins at 10AM PT, so we could spend the first
hour on XRI resolution issues and then switch to ABNF discussion at 10AM when
you are able to join us. I suspect that in two sessions, one
tomorrow and a second on Thursday, we could make substantial progress. =Drummond From: Schleiff, Marty
[mailto:marty.schleiff@boeing.com] On Wednesday I'm can be available between
7:30 and 9:00, and then again from 9:30 tyo 1:00 (Pacific). On Thursday we could use the 8:00-9:00
Metadata call for this discussion. I'm also available for 90 minutes following
the XRI TC call. On Friday I have only one obligation,
between 9:00 and 9:30. Marty.Schleiff@boeing.com;
CISSP From: Drummond
Reed [mailto:drummond.reed@cordance.net] Thanks, Marty and Les, this is a healthy
discussion. I suspect it will be hard to advance it much more via these email
messages; the thread is already quite long. I expect we need some one-on-one
discussions and/or several TC calls devoted to this subject to arrive at a
consensus. Marty, your voice is critical but right
now I know you have a conflict with our new Thursday 10AM PT telecon time. Is
there a time either tomorrow or at a different time on Thursday or Friday when
you would be able to telecon with Les and I and any other TC members that are
able to join? =Drummond From: Schleiff, Marty
[mailto:marty.schleiff@boeing.com] <marty>Well, my
kids tell me I'm not cool, and in this case they're correct. I may eventually
get cool, but I'm not there yet. I've made my responses in fuscia below. Please
don't take my silence on other messages to imply consent. I'm slow, and my
response to this message took me over an hour, so I can't possibly respond to
everything. However, even if my consent is not obtained, in the interest of
making progress I will bend to the will of the TC.</marty> Marty.Schleiff@boeing.com; CISSP
From: Chasen,
Les [mailto:les.chasen@neustar.biz] IMO, that introduces confusion and
therefore complexity but that is just my opinion. I have said it before
and I’ll say it again, there is nothing more important, IMHO, than
getting to the standards track. If Wil, Marty, Steve, Gabe and the other
members of the team are cool then I will be. From: Drummond Reed [mailto:drummond.reed@cordance.net]
Les, I should point out that
=drummond+phone and =drummond*(+phone) differ not just in parentheses, but also
in the use of a local context symbol. <marty>Drummond,
when you're answering questions now, you're answering as if the new proposal is
the gospel. For myself (and possibly others) "=drummond+phone" and
"=drummond*(+phone)" are still equivalent, so there's no difference.
They both use a local context symbol, implied in one, and explicit in the
other. </marty> If we look for a direct analogy in the
English language (and I want to be careful to point out that: a) this is just
an analogy to a human langauge, and b) this particular analogy is to English;
the comparison may be different in other languages), we could ask if the
following two phrases are different?
Drummond’s phone
Drummond’s “phone” At least to me, as a writer, the second
sentence has a subtle but distinctly different meaning than the first. The
first one corresponds to the globally-understood (by English-speaking readers) meaning
of the word “phone”. The second one, by using quotes, suggests that
there is a special *locally-understood
meaning* of the word “phone”. While that latter meaning MIGHT be the
same as the former meaning, it also clearly MIGHT be different. Therefore the
two sentences cannot and should not be assumed to be equivalent. I believe the same should apply to
=drummond+phone and =drummond*(+phone). =Drummond From: Chasen, Les
[mailto:les.chasen@neustar.biz] I personally don’t see it as *significantly* easier. However, if
the rest of the TC does that is fine. I do feel that saying two XRIs,
that are different only in the parens, are not the same is confusing. Why should =drummond+phone be
different than =Drummond*(+phone)? From: Drummond Reed
[mailto:drummond.reed@cordance.net] Les, Marty, see [=Drummond] inline in both
your messages below. From: Chasen, Les
[mailto:les.chasen@neustar.biz] I think you and I are mostly in agreement on the use
of parens. The thing I don't understand is how removing the parens in a
cross reference makes it significantly easier for humans to read and write
XRIs. [=Drummond] I believe the
motivations for the global ref proposal is very simple and clear: it allows you
to concatenate two or more single-segment absolute XRIs directly, with no
special rules about the use of delimiters or parentheses. For example, take the following XRIs, all
of which are independently syntactically valid absolute XRIs: =drummond +phone +work $v*3 Under the global refs proposal, you can
compose composite XRIs out of these component XRIs via direct contatenation
without any special rules. Examples: =drummond+phone =drummond+work =drummond+phone+work =drummond+phone$v*3 =drummond+phone+work$v*3 =drummond+phone$v*3+work$v*2 I suspect that XRI TC members have been
working with parenthetical encapsulation of cross-references for so long that
the notion of direct concatenation of global references seems foreign. However
my experience with individuals outside of the TC is exactly the opposite. Since
they’ve never seen parenthetically-encapsulated identifiers, direct
concatenation is completely intuitive to them, whereas the concept of
parenthetially-encapsulated identifiers is foreign and must be learned. <marty>I suspect
that Drummond been working with Global-Refs for so long that the notion of
parentheses to indicate a reference almost seems foreign. When I showed the
v2.0 schema to a colleague at another company, he read an accompanying
paragraph and immediately recognized what was meant by the parentheses
(obviously he's lots smarter than me). So, my experience has been that the
use of parentheses is understandable (which is a good thing because the
Global-Refs proposal still needs parentheses for the cases Drummond described
below). As I read Drummond's experiences about other people's intuitive
reaction, I also thought it would be nice to conduct some sort of survey,
because I agree that by now we're probably all too close to this to recognize
what is intuitive to a new-comer.</marty> I would go so far as to say that direct
concatenation of identifiers is so simple, intuitive, and useful that as a TC
we should be taking the opposite stance and asking how can we ELIMINATE the
need for parenthetical encapsulation wherever possible. When you take this
perspective, the places where we have found parenthetical encapsulation is
unavoidable is: * Using URIs as cross-references (because
URIs have a different syntax) * Using multi-segment XRIs as
cross-references (because you need to know where the cross-reference ends) * Using multiple cross-references as a
single cross-reference (because you need to know where the cross-reference
ends) Direct concatenation works in all other
cases, so I submit that these should be the only three cases where
parenthetical encapsulation is necessary. See more [=Drummond] inline in
Marty’s message below.
[=Drummond] Correct. By
the logic above, if an XRI author has a reason to not use direct concatenation
where it would be syntactically valid, that reason is known to the author and
should not be overrided by XRI normalization rules.
[=Drummond] While I
understand this sentiment, I believe it needs to be weighed against the
simplicity and intuitiveness of direct concatenation. I doubt anyone on the TC
would argue that direct concatenation is the simplest and most intuitive method
of identifier construction there is. After all, every single sentence I’m
writing here is composed of directly concatenated words (where spaces are the
delimiter). <marty>The
concatenated words in this sentence have no hierarchical relation to the
others. "Every single sentence I'm writing here after all, is composed of
words directly concatenated (where spaces are the delimiter)". My sentence
means the same thing as your sentence in the prior paragraph, even though the
words are in a different order. You can't do that with XRI. If we want to use
natural language as identifiers, then mine would be "the overweight
guy from Boeing that likes XRI, but doesn't like the Global-Refs
proposal", whereas Greg would be either "Greg" or "the
physically fit guy from Boeing that likes XRI, but doesn't have a clue about
Global-refs, but is getting a little tired of waiting for the spec to
mature". Oops! someone might think those aren't good identifiers because
they're not opaque! [=Drummond] I’ll go
on record as saying that I believe the TC would be making a tremendous mistake
if, simply because of our evolutionary path in figuring this all out, we ignore
the power of direct concatenation in the construction of XRIs. I can’t
count the number of times that developers, when first exposed to XRI syntax,
have asked me, “Can’t you get rid of those complicated
parentheses?” <marty>Although
I'm not a hard core developer, I am one of the people who repeatedly whine
about what I consider "over-support" of xrefs. But Drummond, please
recognize that I'm not complaining about parentheses; instead I'm complaining
about supporting the notion of xref in so many of our ABNF rules. For example,
if "$l" really refers to RFC3066, why do we need to support
"$l*(xref)"? An answer I keep hearing is "for extensibility".
Let the people responsible for RFC3066 extend it. If we want some namespace for
languages not covered in RFC3066, we could just set up another namespace (or
anybody else could)to name other languages -- maybe intergalactic languages
aren't covered in RFC3066, so someone might establish "$igl" to hold
inter-galactic languages, or some other namespace not even under "$".
Anyway, enuf ranting about that.</marty> [=Drummond] But you
don’t need to take my word for it. If it would be more scientifically
objective for us to get the opinions of developers, Internet architects, and
others outside the TC about the relative value of direct concatenation vs.
parenthetical encapsulation, I’d be happy to help organize a feedback
session. I still suggest that [=Drummond] Ironically,
the proposed normalization rule – that all delimiters be considered
significant – already tells you that these three XRIs are not equivalent. <marty>The
"proposed normalization rule" only tells us that these three XRIs are
not equivalent IF the proposal gets accepted.</marty> This seems intuitive [=Drummond] Although I
too have been tempted by a mathematical interpretation of parentheses in the
past, I now believe its a red herring. Identifiers are not operators. They are
identifiers. They identify resources using a sequence of characters. Therefore
the fewer normalization rules that are necessary to change this sequence of
characters, the better. <marty>I don't
mean that parens should be treated exactly like they are in math; instead, I
mean the definition of how to treat parens should be concise (like the math
usage is concise vs. the english usage is pretty free-form).</marty>
[=Drummond] Agreed. I
believe that the syntax in http://wiki.oasis-open.org/xri/XriCd02/XriAbnf2dot1
is the most precise we’ve ever had, and the corresponding normalization
rules are the simplest we’ve ever had.
[=Drummond] All the
proposed 2.1 ABNF states is that a ref-value to be optional, which is no
different that the 2.0 ABNF. An empty ref-value is no different than an empty
subsegment or an empty segment. We didn’t invent the concept of an empty
segment -- URI and IRI have long explicitly supported that concept. In URI and
IRI syntax, every segment contains a ref-value (they don’t call it that,
but it’s the same thing), and it’s not required, so it can be empty. [=Drummond] There are
many uses for an empty segment, although I would say that few if any of them
are “intuitive”. Like the number zero, its inherently a complex
concept. <marty>So far I
have heard zero uses for an empty segment, and I don't understand a single one
of them. Does anyone have an example?</marty>
[=Drummond] I strongly
believe that at this point we need to generalize from specific use cases to
general principles. We have spent several years developing XRI syntax to meet
an overall set of design principles. The proposal at http://wiki.oasis-open.org/xri/XriCd02/XriAbnf2dot1
is the simplest and most general ABNF we’ve ever had. To Steve’s
point, it is now as close to a completely abstract syntax as we have been able
to get. [=Drummond] The key point
I’m trying to make it that designing the syntax to the Einsteinein
dictate of “as simple as possible but no simpler” means that we
will have done our best to design a syntax that can be adapted to hundreds of
future use cases for identifiers that we have never anticipated, just as we
have use cases today that we never anticipated three years ago. To use
parenthetical encapsulation as an example: who are we to say to say to the XDI
TC – or any any future producer of XRIs and XRI-based identifier
construction algorithms – that double or triple or quadruple parentheses
should not be significant? The fact that the XDI TC was the first to come up
with that usage reinforces for me the importance of keeping the rules as simple
as possible: if all delimiters are significant, then its very clear what XRIs
can be evaluated as equivalent directly vs. what XRIs must be evaluated as
synonyms via local policy or resolution. <marty>Who's to
say? They syntax authors! The fact that the XDI TC was the first to come
up with that usage reinforces for me the need to do a better job of
defining the syntax (and maybe even the semantics) then was done at the time
the XDI TC came up with that usage. No slam intended - this is of course
exactly what we're all trying to do.</marty> [=Drummond] Again, by the
current proposed normalization rule, none of the four XRIs above are
equivalent. To begin with, they all state that the resource is being identified
in a different global context, so that rules out syntactical equivalence. It
would almost be like saying =drummond and @cordance*drummond should be
syntactically equivalent. They might be proven to be synonyms in that they
identify the same resource via resolution, yes, but to say anything about
syntactical equivalence of identifiers that are not syntactically equivalent
outside of a set of very narrow normalization rules is something I think we
should avoid at all costs.
[=Drummond] Unfortunately
that kind of special exception is antithetical to the concept of a simple,
generalized syntax for XRIs. See my next message to the list regarding this
point, as I believe it’s critical to coming to closure on XRI Syntax 2.1. <marty>Drummond,
when you commented on my statement of preference, you did not attempt to answer
the question; i.e., what determines which GCS to use?</marty> =Drummond |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]