I think it shows we’re allowing the ABNF to be very general and generate complex stuff we don’t understand but would have to support - even as we’re using the ABNF to minutely distinguish cases in some other areas.
What is the use case for allowing variables to contain definitions? I still don’t understand these well.
On 03/09/2015 09:06 PM, Joseph Boyle
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?
If so, why not just vertical bar before instead
of both before and after?
More generally, it’s a waste to use paired
delimiters around single arcs.
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]|}>)]|}
Haha I pasted this into my parser just for fun, and it even made it
to {|[#4]|}
before it gave up with an error!
If we decide this is valid, then it should probably become a unit
test for XDI2 !
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?
Why can an attribute singleton not be an
authority? This seems to be the only difference in content
permitted in entities and attributes.
Do you want to use 1*peer and 1*entity? if not,
how do we interpret zero cases like () and (/)?
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 ")"
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
|