Just noted colons in suggested rules below, perhaps "|"
instead.
From: Barnhill William
[mailto:]
Sent: Thu 6/30/2005 3:21
PM
To:
Subject: RE: [xdi]
abbreviation mechanism for XRI's
Thanks Dave. I see how we can
use xrefs to reference a segment group within the XRI, though that also might be
prone to cycles. I don't immediately see how to use xrefs to delineate a
segment group within an XRI and preserve the semantic meaning of the XRI.
You, Drummond, et al. know XRIs way better than I do, any ideas?
Also, is there a XRI 2.1 or 2.0a rev
planned, and is there any possibility of the ref production going
from
xref =
"(" (XRI-reference / IRI) ")"
to
xref =
"(" (XRI-reference / IRI / "(" (label [":" XRI-Authority ) ")" )
")"
or perhaps the more easier to read
version
xref =
"(" (XRI-reference / IRI / lref ) ")"
lref = "(" (label
[":" XRI-Authority ) ")"
I would need a yacc run to make sure this parses without ambiguity.
If anyone has a yacc or similar xri grammar and wants to try the change I'd
appreciate it, as I won't be able to set that up until later this
weekend.
Which brings up another XRI question:
is xri:(foo*bar)*baz/ equivalent to xri:foo*bar*baz/ ?
How about xri:foo*(bar*baz)/ equivalent to xri:foo*bar*baz/
?
This kind of brings to mind the previous discussion on an algebra
for XRI/XDI, but that's for another day.
Bill
From: Dave McAlpin
[mailto:]
Sent: Thu 6/30/2005 1:50
PM
To: Barnhill William;
Subject:
RE: [xdi] abbreviation mechanism for XRI's
I agree with your
analysis, i.e. square brackets and braces aren’t available and can’t be used.
The only legal characters are in the xri-sub-delims production, and none of
those are “balanced”, like parens or brackets. I think your only option is to
use some form of cross-reference.
Dave
From: Barnhill
William [mailto:]
Sent: Thursday, June 30, 2005 10:43
AM
To:
Subject: FW: [xdi] abbreviation mechanism
for XRI's
I did a little digging
into the XRI 2.0 and IRI specs.
"[" and "]" Are
xri-gen-delims, which does mean they are currently reserved, so this would
require an XRI spec mod.
However, XRI makes no use of these
chars, they're marked as xri-gen-delims as they are reserved in
IRI.
Their use within IRI is for IP
literals (ie. for IPv6+). With that in mind "[" are prob out. Perhaps "{" "}",
which are not covered under XRI or IRI. Of course then we have the problem of
readability between "{}" and "()". Brackets would be ideal, but then
XDI addresses would not be XRIs, or XRIs would not be IRIs, neither of
which are acceptable I'd think.
Another option, though somewhat ugly
is ((label:oneormoresegments)) which also makes the grouping looking like a
special kind of cross-reference, which in a very loose sense it would seem to
be. The following would reference the labelled segments ((label)). This may be
the most workable as ")" is a xri-sub-delim, and it may be in line with our
current use of "(", though I'm leary of making "("'s meaning depend on the
character that follows it.
Bill
Barnhill
Senior Consultant
(XML, Emerging Technologies, Web Services, Java)
Booz | Allen |
Hamilton
mailto:
phone:+1.315.330.7386
From:
[mailto:]
Sent: Thu 6/30/2005 12:00 PM
To:
Subject: [xdi] abbreviation mechanism for
XRI's
I like this a lot
and will start using it in my documents. However... Is it valid for XRI 2.0? if
not I'm not going to include support for it in the actual implementations (for
now).
Dave? Drummond?
Andy
Dale
ooTao
Phone: 877-213-7935
Fax: 877-213-7935
i-name:
=Andy.Dale
http://public.xdi.org/=andy.dale
***************************************************************************
If
you don't have your iName yet use this link:
http://2idi.com/registrar/index.html?referral_code=ootao
***************************************************************************
"Barnhill
William" <>
06/30/2005 06:32
AM
To
<>
cc
Subject
RE: [xdi] Dollar
word proposed for data
types-$type
Ah, ok. I
thought it was $l-en. If we used hierarchy for the $l system I agree, we should
use it for this as well. Also, after thinking about it hierarchy does make
sense, though it adds more parens.
What are
everyone's thoughts on a possible abbreviation mechanism for XRI's, and on the
following ideas for such an mechanism? IMHO some of the XRIs we're using in our
examples are very long, and an abbreviation scheme would be nice for five
reasons:
(1) Increased human readability (low priority)
(2) Decreased
bandwidth (high priority)
(3) Streamlined XRI parsing (if you parse an
abbreviated authority once, you can cache it for rest of XRI. Implementers will
do caching anyway, but an abbreviation would make recognizing when to pull from
cache easier)
(4) If we want people to be able to type XRIs or, more likely,
use them as links in a browser, then I seem to remember a 256 character limit in
IE, possibly other browsers. That limit may have been removed by now, I'm
don't know.
(5) Referencing parts of the XRI in the XRI processing
The scheme I'm thinking of would use some grouping characters not
used by XRI spec currently..[], perhaps? These would be used in a manner similar
to the way regex groups work. Where you have a repeated XDI addressing path xxx,
you'd replace the first instance with [somelabel|xxx] and further instances with
[somelabel]. For most cases this would be [1|xxx] and [1]. Another decision
would be whether or not to allow nesting.
Bill
Barnhill
Senior Consultant (XML, Emerging
Technologies, Web Services, Java)
Booz | Allen |
Hamilton
mailto:
phone:+1.315.330.7386
From: Drummond
Reed [mailto:]
Sent: Wed 6/29/2005 11:59 PM
To: Barnhill William
Subject: RE: [xdi] Dollar word proposed
for data types-$type
Cool idea. $type is already one of our "default dollar
words" by virtue of
being one of the XDI schema elements. And at first blush
this seems like a
good use of it. I also like the idea of making the fragment
identifiers in
the W3C Schema Datatypes spec the default.
I also
suggest we go with true hierarchy, i.e., slash. This is what we did
with $l
in the XRI Metadata spec - slash delineates the instances of the
type,
whereas * delegates to subtypes. For example with $l, the immediate
children
(i.e., if there is no delegated *name after $l) are defined to be
two-letter
language tags from (I forget the name of the RFC - see the spec
at
http://www.oasis-open.org/committees/download.php/11854/xri-metadata-V2.0-cd
-01.pdf). For example:
$l/en for
English
$l/fr
for French
So with the $type space, we would specify (in the Service
Dictionary spec)
that the default child namespace under $type is the set of
fragment
identifier in the W3C Schema datatypes spec.
$type/string
$type/float
Then
you could extend type definition to any other namespace as
follows:
$type*(=foo/mytypes)/custom.type
Sure meets the simplicity test.
Thoughts?
=Drummond
-----Original Message-----
From:
[mailto:]
Sent: Wednesday, June 29, 2005 7:25
PM
To:
Subject: [xdi] Dollar word proposed for
data types-$type
$type-xxx where xxx is the fragment identifier from the
W3C schema datatype
or $type-yyy-xxx where yyy is the ident for a type system
other than W3C
schema
datatypes.
--
Checked by AVG Anti-Virus.
Version: 7.0.323 / Virus Database: 267.8.7/34 - Release Date: 6/29/2005
