RE: PROV-ISSUE-438 (prov-n-post-f2f3-review ): Final review before last call vote [prov-n]

Hi Stian,

My understanding is that tokenizers, by default, create tokens irrespective of their occurrence in
the parse tree.

It means means that a tokenizer has no way to decide between QUALIFIED_NAME and INT_LITERAL for 1234.

The purpose of the note is simply to bring this issue to the attention of the developer, and suggest a way
to address it, by saying that INT_LITERAL should be chosen in the context of a Literal.


Luc

________________________________________
From: stian@mygrid.org.uk [stian@mygrid.org.uk] on behalf of Stian Soiland-Reyes [soiland-reyes@cs.manchester.ac.uk]
Sent: Monday, July 09, 2012 11:32 AM
To: Luc Moreau
Cc: public-prov-wg@w3.org
Subject: Re: PROV-ISSUE-438 (prov-n-post-f2f3-review ): Final review before last call vote [prov-n]

Sorry this is dragging out, folks, I'm just confused why the
"precedence" warning is here at all since I don't see any conflict in
either case. Please provide examples of a conflict that would arise if
the 'precedence' is not added.


On Mon, Jul 9, 2012 at 10:48 AM, Luc Moreau <L.Moreau@ecs.soton.ac.uk> wrote:

> But we do have a conflict, given that
> 1234 can be both a INT_LITERAL and a QUALIFIED_NAME
>
> I am not sure what you are saying.

Perhaps I am not good with parsers - but I don't see any expressions
in the grammar where you can have both an INT_LITERAL and
QUALIFIED_NAME - and don't see the need for stating this. Perhaps it's
good to just clarify it without using the word "precedence".


> - Should we change the grammar and avoid conflict?
> - Should the text  ' a parser should give precedence to the production
> INT_LITERAL' be changed?

No, they are both fine - there is no conflict.



> This said, your solution is actually supported indirectly, with the
> following
>
> bundle
>   prefix exfred<http://example.com/?fred=fish%20soup>
>   entity(exfred:)
> endBundle

Yes, that is what you are alluring to with "or incorporated in the IRI
denoted by a prefix" - but it is not a good solution. For instance
incremental PROV-N generators can't change prefixes as they go along
(prefix has to be in the beginning of 'bundle' statement - which is
good). This would also pollute the namespace prefixes for every entity
with a 'difficult' URI.

> Thoughts?

I would let the community comment on this and see if it is rather
needed a <IRI> syntax.

Perhaps make a note that not all IRIs can easily be expressed as
localnames, and that the current best practice would be to use as a
fallback a dedicated prefix and with an empty localname.



> So to clarify, the correct production is
> namespaceDeclaration       ::=          "prefix" PN_PREFIX namespace
>
> Again, there is a conflict between PN_PREFIX and QUALIFIED_NAME.
>
> abc can be both a PN_PREFIX and a QUALIFIED_NAME.

.. but not in the same context. 'entity' can be both a QUALIFIED_NAME
and the beginning of an entityExpression - but we don't declare that
as a problem of precedence.

  activity(entity)
  entity(activity)

is valid.

Perhaps I don't know enough about tokenizing parsers - in my
experience they often give you the wrong thing if the grammar is not
finely tuned - perhaps this is what you mean, if you are using a
parser that expects only one rule to match at any point in time while
ignoring the context. But this can't work well, because eIdentifier,
aIdentifier, eIdentifierOrMarker, etc. would all match "fred:soup" if
you ignore context.

It just sounds odd to me that you say "within the context of
namespaceDeclaration, PN_PREFIX should be given precedence" - well of
course, it's the only thing allowed there! ;-)


> I don't see this  as an issue, as long as PN_PREFIX is preferred over
> QUALIFIED_NAME
> in the context of the namespaceDeclaration.

You can't have a QUALIFIED_NAME in the context of the corrected
namespaceDeclaration - there is no conflict. So I am not sure why the
precedence text is there.


--
Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester

Received on Monday, 9 July 2012 11:37:53 UTC