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] Full Graph Model ABNF Test


Maybe the ordering can change it, not sure.
Rather than experimenting, we'd really have to understand how these parsers work internally, in order to design the "perfect" ABNF.

So I'll stick with the "Segment-Based ABNF" for now.

But let me know if you come up with something..

Markus

On Sat, Feb 23, 2013 at 8:16 PM, Joseph Boyle <boyle.joseph@gmail.com> wrote:
Does changing the order of the rules do anything?

Probably xref should be removed from the rules for generic .. immutable and treated separately from the literal cases. xref can be recursive while xdi-literal is terminal.

I've been thinking about how to code a top-down parser for cases when detailed parsing is not necessary, or you want to detect high-level errors and give the highest-level error message.
I'm thinking the top-level scan will split the input string on / and ( and ), while ignoring the gcs/lcs delimiters leaving them for subsequent separate parsing of each literal segment.

On Feb 23, 2013, at 9:44 AM, Markus Sabadello <markus.sabadello@xdi.org> wrote:

So I tried to use the APG parser generator with the proposed Full Graph Model ABNF on a few sample XDI statements.

For example, I tried to run it on this:
=markus$!(+name)/!/(data:,MarkusSabadello)

... and I ran into 2 problems.

First problem:

According to the ABNF, $!(+name) is a valid entity-singleton.
This doesn't have a big effect on the overall parsing process, but it's not correct.

Second problem:

The parser doesn't actually recognize the whole string as a valid XDI statement.

Why? Let's look at the ABNF rule that has to be satisfied:
literal = [ context ] literal-context "/!/" data-xref
Now what happens is that the parser thinks that the context part of this is matched by =markus$!(+name), which leaves nothing to match the literal-context, therefore, parsing fails.

Instead, what should happen is that the context part is matched by only =markus, and that the literal-context part is matched by $!(+name).

But for some reason the parser isn't able to figure that out.

I know this has something to do with the parsing algorithm, with left recursion, and with backtracking, but I'd have to read up on these concepts to fully understand the problem.

I also found this, very interesting:

Markus








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