OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Yettanuther Syntax Proposal


After three weeks of trying, I suggest we abandon efforts to contrive
meaningful grammar to match the rich syntax of direct concatenation.
It's not been completely fruitless, because we've learned that there is
no obvious difference in the meaning of direct concatenated global ref
vs. a local ref with parens enveloping a globally-rooted XRI. So,
instead of focussing on coming up with richer ways to express concepts
for which we have no use cases, I suggest we focus on simpler ways to
express very flexible concepts. As a starting point for consideration, I
suggest the following:

1.	There are only three types of values that can be in a
subsegment; a local value, a rooted value (one beginning with a GCS), or
a parenthetical cross reference.
a.	example        // Example of a local literal
b.	@example     // Example of a rooted literal:
c.	(@example*stuff)   // Example of a parenthetical cross
reference. 

2.	A parenthetical cross reference is required in two cases:
a.	An XRI with more than one subsegment or segment is to be taken
into the context of another XRI.
b.	An IRI is to be taken into the context of an XRI.
c.	Note - If a single subsegment XRI is enveloped in parens when
taken into the context of another XRI, the parens are unnecessary.
Normalization rules may be necessary.

3.	There are three global namespaces in which a rooted literal can
be rooted; @, =, $.

4.	There are only three subsegment delimiters; star, bang, and
plus. Subsegments of a segment are ALWAYS delimited by either a star,
bang, or plus. 
a.	@example*stuff                      // "stuff" is a local
literal
b.	@example!stuff                       // "stuff" is a persistent
local literal
c.	@example+stuff                      // "stuff" is a tag with the
meaning of the tag determined by @example
d.	=steve*@microsoft.com                    // "@microsoft.com" is
a rooted literal. I hope this helps address steve's social vulnerability
issue, even though my word processor still considers this an email
address, even with the @ preceded by *.
e.	=steve!@microsoft.com          // "@microsoft.com" is a rooted
literal, and "=steve" claims that it is persistent (although I'm not
sure it makes sense for =steve to make such a claim).
f.	=marty*(@example*stuff)       // "(@example*stuff) is a
parenthetical cross reference referencing a particular resource. When
taken into the context of "=marty" as a parenthetical cross reference,
it means the same resource with associated attributes and/or service
points provided by =marty. 
g.	=marty!(@example*stuff)       // same as before, but =marty
claims the whole cross reference is persistent.

5.	A plus can only be followed by a local literal.
a.	 @example+stuff                      // "stuff" is a tag with
the meaning of the tag determined by @example

6.	Star and bang can be followed by any of the three types of
subsegments (local literal, rooted literal, parenthetical cross
reference)

7.	The grammatical difference between the three subsegment
delimiters is as follows:
a.	!     // this means the following subsegment is persistent
b.	*    // this means the following subsegment may be reassignable.
When a star preceeds a local literal, it means that the local literal
conveys no meaning to a relying party - it's just the name of a
namespace or resource in a namespace.
c.	+    // this means the following local literal is a tag,
intended to convey a particular meaning. The meaning is decreed by the
"context" in which the tag appears (i.e., by the combined preceding
subsegments). Parties/communities that use tags will benefit by having a
common decree about the meaning of the tag values used in the community.

8.	Each subsegment is in the context of everything to its left (as
represented in the abstract model - i.e., to the left on the same
level).
a.	@example*stuff             // "stuff" is a local literal in the
context of @example.
b.	@example*stuff*morestuff       // "morestuff" is a local literal
in the context of "@example*stuff".
c.	@example*half-full*=marty      // "=marty" in the context of
"@example*half-full", which might consider =marty's reputation to be
"excellent on even numbered days".
d.	@example*half-empty*=marty      // "=marty" in the context of
"@example*half-empty", which might consider =marty's reputation to be
"lousy on odd numbered days".
e.	@example*=marty*stuff                   // "stuff" is in the
context of "@example=marty"; not in the context of "=marty".
f.	@example*(=marty*stuff)                 // "stuff" is a
subsegment of "=marty*stuff". "stuff" is not a "top level" subsegment of
"@example*(=marty*stuff)".
g.	=drummond+home+phone               // "+phone" is in the context
of "=drummond+home".

9.	I still haven't figured out what to do about <gcs>!<literal>,
and I need some help with it. I think it would be easier if ! were not a
delimiter, but just a claim of persistence, but I don't think you guys
will agree with that.
a.	@!123.234.345    // because ! is a delimiter, this whole thing
can't be termed a rooted literal. I need help with this.

10.	If people don't like * in front of a rooted literal subsegment,
I suppose we could decide to leave it off syntactically, but still
include it in spirit (i.e., even though you don't see it, it's still
there). However, that would get rid of any benefit the "*" provides
against social vulnerability (see example 3.d.).

I'm not hard-set on any of this, but I think it incorporates a lot of
the ideas we've discussed over the past weeks. These ideas represent
simpler syntax, simpler grammar, and I still think they address all the
use cases that have been suggested. I think it provides a nice solution
for the most common desire for direct concatenation (i.e., + tags as in
6.f.). And it also clears up my grief about "+" not being a global
namespace. 

Marty.Schleiff@boeing.com; CISSP
Associate Technical Fellow - Cyber Identity Specialist
Computing Security Infrastructure
(206) 679-5933


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]