Re: [xdi] Updated XDI ABNF page

[Markus Sabadello <markus.sabadello@xdi.org>]

Also note that there is some ambiguity in the current ABNF.

For example, if you have the following "xref":

(data:,markus.sabadello@gmail.com)

Then that could be parsed either as "xref-IRI" or as "xref-subject".

This doesn't change anything about validity, but it makes a semantic difference for an XDI processor.

BTW Drummond is there a reason why you replaced "xdi-context" with "xdi-subject"?

I realize it reduces the number of rules, but still for semantic reasons I think I'd prefer to keep it.

Keep in mind that an XDI processor doesn't just care whether a statement/address/etc. is valid, but it also cares about (some of) the sub-rules it decomposes into.

Markus

On Wed, Jan 30, 2013 at 8:58 AM, Markus Sabadello <markus.sabadello@xdi.org> wrote:

Yes we could try this, and I agree it would really speed up parsing.

But I am always worried that then somehow the XDI server might not be 100% correct when it comes to accepting valid XDI data.

Having said that, it seems APG has a feature called "user-defined terminals", which apparently allows you parse parts of the ABNF tree "manually", without going through all the rules.

Maybe this could be used for the IRI part of it, I think then the code would not validate the IRI part, but still apply the ABNF rules to the rest.

Markus

On Wed, Jan 30, 2013 at 4:28 AM, Joseph Boyle <planetwork@josephboyle.net> wrote:

I would advocate not parsing IRIs, but just scanning from "(" to ")" where an IRI is expected and storing the result. Throwing out the IRI grammar and handling only XDI's own syntax would simplify parsing to the point where we don't even need a parser generator. 

Verifying the IRI general grammar has little value as it doesn't verify other details of each scheme or show that references are actually dereferenceable on the net. Let the HTTP libraries do URL processing including verification. 

Sent from my iPhone

On Jan 29, 2013, at 4:25 PM, Markus Sabadello <markus.sabadello@xdi.org> wrote:

This looks great to me, actually the fact that on one hand,

1) XDI syntax included XRI syntax, and that on the other hand,

2) there were so many parallel rules,

... has bothered me for a while.

I will try it out in my implementation shortly.

The one fix I have right now is to change "iri" to "IRI", I just updated that on the page.

I have actually been spending some time recently on the XRI/XDI parser component of XDI2.

While doing so, I have looked at a new parser library called APG as a potential alternative to aParse which I had been using so far.

Will report back on this.

Markus

On Tue, Jan 29, 2013 at 7:54 AM, Drummond Reed <drummond.reed@xdi.org> wrote:

Per last week's telecon, I have updated the XDI ABNF page 

   https://wiki.oasis-open.org/xdi/XdiAbnf

...to incorporate the InnerRoots proposal:

   https://wiki.oasis-open.org/xdi/InnerRoots

When I made the edits, I realized that by adding just 6 more lines, and where necessary changing the rule name prefix to "xdi-", we could eliminate any dependency on the XRI 3.0 ABNF. In other words, the entire XDI ABNF would stand on its own, with the only referenced ABNF rules being those from the IRI spec (which is exactly the same with the XRI 3.0 spec).

This has two advantages:

1. It eliminates the need for anyone reviewing the spec to need to check another external spec (besides the IRI spec, which we must reference) to review the complete XDI ABNF.
2. It eliminates any dependency on XRI 3.0 needing to advance (which is not necessarily an issue, but just one less dependency to worry about).

Just to clarify, this didn't involve making any changes to the ABNF, just including all the complete set of ABNF rules in one place.

=Drummond