[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] Yettanuther Syntax Proposal
Hmm ... interesting. How does this all map into the abstract syntax? I think you are saying I can't have @cordance=Drummond but I could have @cordance*=Drummond. How does that equate to @cordance*(=Drummond)? Are they equivalent or not? I think in the mathematical model they would be but in the language model they are not. I think I kinda like the use of * and ! as it clearly preserves delegation. I am a fan of downgrading + to a LCS to allow easy tagging. contact: =les sip: =les/(+phone) chat: =les/skype/chat > -----Original Message----- > From: Schleiff, Marty [mailto:marty.schleiff@boeing.com] > Sent: Friday, May 11, 2007 12:11 PM > To: xri@lists.oasis-open.org > Subject: [xri] 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]