[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
<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
Associate Technical Fellow - Cyber Identity Specialist Computing Security Infrastructure (206) 679-5933 From: Chasen, Les [mailto:les.chasen@neustar.biz] Sent: Tuesday, March 13, 2007 2:21 PM To: Drummond Reed; Schleiff, Marty; xri@lists.oasis-open.org Subject: RE: [xri] Proposal for XRI Syntax 2.1 to treat all delimiters as signficant 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?” 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.
[=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]