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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xdi message

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


Subject: Re: [xdi] Collected ABNF ready for review (starting with Joseph & Markus)


On Mon, Mar 9, 2015 at 1:06 PM, Joseph Boyle <planetwork@josephboyle.net> wrote:
Drummond, here are a few initial review questions:

Are definitions as well as variables, collections, and everything else (but inner roots) limited to a single arc?

Yes.
 
If so, why not just vertical bar before instead of both before and after?

In my personal opinion, even though vertical bars are not technically paired delimiters like parentheses, square brackets, or squiggly brackets, we are using them that way, and it would be more confusing to not use them as pairs.

 
More generally, it’s a waste to use paired delimiters around single arcs.

While again you are technically correct, the precedent of paired brackets has been widely set—for example in JSON—and they are easier to read in pairs.

 

Let’s try to construct a maximal nesting example. Is this in fact grammatical and a single arc? Is there any of this nesting that we should rule out either at the syntactic level or higher levels?

{|[(({|[#1]|})({|[#2]|}){|[#3]|}<{|[#4]|}>/({|[#5]|})({|[#6]|}){|[#7]|}<{|[#8]|}>)]|}

Boy, it took me a long time to parse this manually - a defined variable containing an inner root where both the subject and predicate have four variables—but I believe it's syntactically valid (don't take my word for that as I haven't taken the time to carefully check every character).

But you can always compose extreme edge-case examples. I'm not sure what that proves?

 
Why does class have the option of being one of six context symbols followed by nothing, four of which are normally in authorities or instances not classes?

Because, by themselves, those symbols are classes. In other words, two of the context symbols ($ and #) are metaclasses, so all instances (when you add id-literals) are classes. The other four (@, *, =, +) are classes, so all instances (when you add id-literals) are instances.
 

Why can an attribute singleton not be an authority? This seems to be the only difference in content permitted in entities and attributes.

You're right, that is the only difference. Obviously an authority singleton can be an entity; arguable they are the most important entities. But, because an authority instance is not a class, it cannot be an attribute. The only instances that can be attributes are @ or * instances of attribute classes, and an attribute class must be a $ or # class.
 

Do you want to use 1*peer and 1*entity? if not, how do we interpret zero cases like () and (/)?

I know you studied it carefully because you spotted that! Here's the answer: for the peer and inner rules, I originally had 1*peer and 1*entity. However I realized that in root variables, we needed {()} and {(/)} as typed variables to match a peer root and an inner root, respectively.

So I thought about it and concluded that both were valid use cases.
  • () represents an empty peer root, which is addressable like any other peer root.
  • (/) represents the inner root that reifies the contextual statements between the common root and any first-level context. For example, (/)=markus<$t> would be a timestamp for when the context =markus was added to the top level of that graph.
Great questions. Keep 'em coming.

=Drummond 
 

root                    = peer / inner / root-collection / root-definition / root-variable
peer                    = "(" *entity ")"
inner                   = "(" *peer / *entity "/" *entity ")"
root-collection         = "[" peer / inner "]"
root-definition         = "|" peer / inner / root-collection "|"
root-variable           = "{" peer / inner / root-collection / root-definition "}"

entity                  = singleton / collection / definition / variable
singleton               = class / instance / authority
collection              = "[" class "]"
definition              = "|" class / authority / collection "|"
variable                = "{" singleton / collection / definition "}"

attr                    = attr-singleton / attr-collection / attr-definition / attr-variable
attr-singleton          = attr-class / attr-instance
attr-collection         = "[" attr-class "]"
attr-definition         = "|" attr-class / attr-authority / attr-collection "|"
attr-variable           = "{" attr-singleton / attr-collection / attr-definition "}"
attr-class              = "<" class ">"
attr-instance           = "<" instance ">"
attr-authority          = "<" authority ">"
attr-terminal           = attr-class / ( attr-collection attr-instance )

class                   = reserved / unreserved / "$" / "#" / "@" / "*" / "=" / +"
reserved                = "$" 1*xdi-char
unreserved              = "#" id-literal

instance                =  ordered / unordered
ordered                 = "@" [ "!" ] 1*DIGIT
unordered               = "*" [ "!" ] id-literal

authority               = personal / legal
personal                = "=" [ "!" ] id-literal
legal                   = "+" [ "!" ] id-literal

id-literal              = 1*xdi-char / xdi-scheme / xref
xref                    = local / uri
local                   = "(" 1*xdi-char ")"
uri                     = "(" escaped-uri ")"



On Mar 8, 2015, at 5:28 PM, =Drummond Reed <drummond@respectnetwork.com> wrote:

After Friday's very long TC call reviewing the "star shift", "immutability symbol", and "xref" proposals (see https://wiki.oasis-open.org/xdi/StarShift), this weekend I worked on an update to the XDI ABNF that I just uploaded to the ABNF page:


I was excited to work on this ABNF because, as I had predicated on Friday, it is significantly more simplified, regular, and elegant than any previous version. (And no longer recursive, which will finally make Joseph happy ;-)

The next step is for Joseph and Markus to review and test it carefully, and for Joseph to attend to some remaining to-dos on the low-level rulesets. There is also one open question about what versions of SHA hashing do we want to support as native XDI schemes. Please feel free to weigh on this thread with your view.

=Drummond 




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