[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] Potential breakthrough
|
Steve, To answer your question: “Why does
the XDI RDF client need to be able to distinguish between @cordance+west and
@cordance*(+west)?” 1) First, because those two identifiers express
different contexts. + is a different context than *, no matter WHAT follows the
star. To say that the + context and the * context are the same context is to
break the purpose of context symbols in XRI syntax. 2) Secondly, because those two identifiers
are different – SIGNIFICANTLY different – to a human reading them. To
introduce an equivalence rule that would require every human that reads XRIs to
understand that rule would be to move the processing burden from machines to
people. Not only should our goal be to do the opposite, but in fact this is a
stated requirement of the TC. To quote from the first deliverable of the XRI TC
on June 13, 2003: http://www.oasis-open.org/committees/download.php/2523/xri-requirements-and-glossary-v1.0.doc SECTION 3.4: Human-Friendly and Machine-Friendly Identification
Human-Friendly Identifiers (HFIs)
The XRI specifications must support the ability to
create identifiers optimized for human readability, memorability, and usability.
=Drummond From: Steven Churchill
[mailto:steven.churchill@xdi.org] Drummond, > a client (for example an XDI RDF
client) needs to be able to tell from an XRI parser that they are not the same
identifier. I am trying to dig into specifics. You are
making a case that the 2.0 abstract syntax fails to satisfy certain use cases,
but statements such as those above do little shed light onto what use cases
fail. Why does the XDI RDF client need to be able to distinguish between
@cordance+west and @cordance*(+west)? ~ Steve From: Drummond
Reed [mailto:drummond.reed@cordance.net] Steve, The list of XRIs I gave as examples in my
email all happened to “normalize” to different XRIs. But as soon as
you normalize two different XRIs to the same XRI, then the client of a parser
can’t tell the difference between the two original XRIs. An example would be @cordance+west and
@cordance*(+west). My email explained that these are different identifiers
expressing different contexts for the identifier “west”, and thus a
client (for example an XDI RDF client) needs to be able to tell from an XRI
parser that they are not the same identifier. If the parser normalizes either
one into the other, the difference in the context information is lost. I hope that is clearer. This will probably
be easier to talk about on the call tomorrow. =Drummond From: Steven Churchill
[mailto:steven.churchill@xdi.org] Drummond: > For example, +west, +direction+west,
@cordance+west, and @cordance*west all > make very precise assertions about
the context of the identifier “west”. But if we normalize these
identifiers to the 2.0 abstract sytax tree, then we get 4
different syntax trees: +west +direction*(+west) @cordance*(+west) @cordance*west Thus, to the client-of-the-parser, 2.0
abstract syntax seems to satisfy the requirements of this use case. As far as my question from below: Can we identify a parser client who's use case is not satisfied by
the 2.0 abstract syntax? I still don't see the use case where 2.0
abstract syntax fails. I'm not saying that it doesn't fail, I'm just saying I
don't see yet where it fails. ~ Steve From: Drummond
Reed [mailto:drummond.reed@cordance.net] Steve, I think I explained that in my email last
night. But I can sum it up in just a few sentences: 1) The identifiers +west and *west are not
equivalent because they each express the identifier “west” in a
different context. 2) The identifiers *(+west) and !(+west)
are also not equivalent for the same reason. 3) The identifiers +west, *west, *(+west)
and !(+west) are also not equivalent for the same reason. Specially, the last
two express “a cross-reference to the reassignable identifier +west in a
local context” and “a cross-reference to the persistent identifier
+west in a local context”, respectively. 4) In XDI RDF, to take just one
application, XRI authors and users need to be able to express/understand
identifiers in both local and global contexts. For example, +west,
+direction+west, @cordance+west, and @cordance*west all make very precise
assertions about the context of the identifier “west”. To force
+west to be either *(+west) or !(+west) in any of the above identifiers would
change these assertions, not just for machines, but for the humans that need to
understand them. What’s worse, rather than making complex things simple,
they would force simple things to be complex. Given that XDI RDF (among other
applications) relies on very precise identification of resources and contexts
– that needs to be understandable by both machines and people – 2.0
syntax doesn’t meet this requirement. I hope this helps. I fully understand the
amount work involved with rev’ing an XRI parser to 2.1 syntax.
(It’s worth pointing out that not all this work is due to supporting
direct concatenation – 2.1 involves other important revisions too.) =Drummond From: Steven Churchill
[mailto:steven.churchill@xdi.org] I wrote: > To answer this question, I would ask
the following: Can
we identify a parser > client who's use case is not satisfied by the
2.0 abstract syntax? Drummon, bbviously, you have one in the
form of the XDI-RDF-processor-as-client. We should explore precisely why this
use case isn't satisfied by 2.0 abstract syntax. ~ Steve From: Steven
Churchill [mailto:steven.churchill@xdi.org] Drummond, I think the best approach at this point is
to address the 100 lb gorilla issue head on: 100 lb gorilla issue: Should we be changing the 2.0
abstract syntax? [Note that this question exists with or
without the compact syntax, because the compact syntax can be normalized,
if we so decide, to the 2.0 abstract syntax.] To answer this question, I would ask the
following: Can we
identify a parser client who's use case is not satisfied by the 2.0 abstract
syntax? [If we take the approach of working from
the ABNF up, then we are still going to need to confront the gorilla issue at
some later time.] ~ Steve From: Drummond
Reed [mailto:drummond.reed@cordance.net] I have an internal maxim that I follow: if Steve tells me
he’s got a problem with something, and after three times trying to work
it out with him, he’s still got a problem with it, then I need to look at
it very closely and see if there’s a better solution. I’ve worked long enough with Marty now to realize the
same thing is true with him. So when both of them plus Wil are telling me something is
too complex, that’s one helluva strong signal. So after yesterday’s thread, I looked closely at the
requirements again and thought about the key issue Steve has raised about how
“sticky stars” makes for funky synonym rules. This jibes with what
Marty keeps saying about how the original “compact syntax” was much
simpler than “sticky stars”. I have always been the one saying that we needed sticky
stars. So I revisited that assumption…and realized that in that area I
too had been stuck with a “2.0” filter on. I had been assuming that
anything you could express as a parenthetical xref (which is
“opaque” to XRI resolution) had to be something that was also
equally “opaque” when expressed as a global-xref. But it’s that assumption that leads both to most of
the increased complexity and the funky synonym problem. So if you drop that
assumption and do as Marty has been suggesting all along and simply treat all
subsegments as subsegments… …everything works just fine. To illustrate, take Steve’s @ootao+west*steve and
@ootao*west*steve example. The current 2.1 syntax proposal requires these parse
into separate trees: @ ootao +west*steve @ ootao *west *steve But if you drop the requirement that global-xrefs need to be
syntactically opaque, they would both parse into the same trees, with the only
difference being the type of one subsegment: @ ootao +west *steve @ ootao *west *steve The funky synonym problem goes away because all subsegments
are subsegments, and if @ootao wants to declare +west and *west as synonyms, it
doesn’t affect any other synonyms lower in the tree. But you still get
the semantic precision of @ootao being able to express that +west is intended
to be a generic dictionary identifier vs. *west a local name without any
expectation of cross-referencability. So I tried to figure out if there was any other requirement
– in XDI RDF or anywhere else global-xrefs would be used – that
would not be met if global-xrefs were not opaque. I couldn’t come up with
any. If so, we could essentially have our cake and eat it too.
The ABNF would get significantly simpler, and we’d get all the semantic
simplicity/richness of direct concatenation, but without any of the pain of
funky synonyms or increase resolution complexity. Frankly, I’m still trying to figure out why I was so
stuck on “sticky stars” (so to speak ;-). After all, Marty has
repeatedly said things would be much simpler without them. But then, sometimes
when something’s stuck in your head, it takes a real jolt to knock it
out. I’ll take a pass on the simpler ABNF that reflects all
this as soon as I get a break today – worst case I’ll try to have
something published by tonight. =Drummond |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]