Re: Keeping PrEfIx and BaSe Proposals

On Thu, May 30, 2013 at 2:58 AM, Andy Seaborne <
andy.seaborne@epimorphics.com> wrote:

> I'm surprised that I have to mention this:
>
> #resolution_2 was to keep "the feature in the document" [1] and the
> questionnaire was also specific.
>
> This set of proposals goes beyond the "feature at risk" as signalled in
> the LC.  I don't actually care very much on the designs except for the
> SPARQL redesign but we are post-LC and need to take care (or go for another
> LC).  We have to finish.
>
> [1] https://www.w3.org/2013/**meeting/rdf-wg/2013-05-29#**resolution_2<https://www.w3.org/2013/meeting/rdf-wg/2013-05-29#resolution_2>


Indeed, and as mentioned by both yourself and the rejected proposal was
that all of the feedback from outside the group had been idea is not bad,
DON'T ADD FEATURE. We chose to ignore this feedback. With that feedback
came a great deal of resistance to the feature as specified in the
document, I don't think anyone planed on implementing as is, see case
issues, and trailing dot issues. So while we resolved to do exactly what
the current document says I doubt anyone in fact did or plans on doing
exactly what the document said. See your own implementation of optional
trailing periods.

The resolution said, keep the feature not keep the implementation ;)


>
>
> On 29/05/13 17:29, Gavin Carothers wrote:
>
>> Turtle Proposals
>>
>> 1. Keywords should all have the same case rules. @prefix, @base and a
>> should allow for upper-casing
>>
>
> -0.1
>
> The @ forms are the traditional way of writing directives - just leave
> them as they are, especially if the "prefix" forms are supposed to be the
> preferred form.
>

So we're back to the case where we had comments objecting to having some
keywords case sensitive and some not :\ The "" vs. '' in the grammar really
isn't clear enough, nor is it clear design wise why given we're introducing
case insensitivity for directives.


>
> -0.5 if the doc describes PREFIX as the preferred form in any way.
>
>
>  2. Directives should all have optional trailing periods.
>>
>
> +1 - optional for @ forms (I've just added this for my parser)
> Does not break existing data.
>
> -1 for keyword forms.  Long term, the use of dot should be where
> necessary, not as a general feature to be expected.
>
> More in a separate reply.



base <http://one.example/> <subject> <predicate> <object>

That is one strange Turtle file. :\ Periods help with human readability not
machine. Unlike SPARQL there is no {} offsetting triples from directives.


>
>
>  3. Turtle should include examples of both forms of PREFIX @prefix
>> directives.
>>
>
> Yes.
>
>  4. Turtle serializes SHOULD output directives using the '@' notation
>> with trailing periods.
>>
>
> Difficult and important but what the documents says or recommends about
> serialization is a separate from the resolution detail of what the grammar
> contains.
>
> Openlink have already indicated they will emit the traditional forms and I
> think many others will choose to do the same for a while yet.
>

Indeed, want to make sure that a new implementer and someone unaware of
history is able to make the same good choice.


>
> SHOULD is quite strong.
>
> I suggest no use of RFC 2119 language (and really, no normative text).
>

Okay, just want to make sure there is some reasonably strong guidance not
to start publishing PREFIX style Turtle documents next week.


>
> But if there is an preferred form, are the test going to be updated to
> that form where the @prefix is not the point of the test.
>
>
>  If there are no loud objections to these changes, will update the
>> document accordingly.
>>
>> Example grammar change from gkellog:
>>
>> [4] prefixID ::= '@'? [Pp][Rr][Ee][Ff][Ii][Xx] PNAME_NS IRIREF "."?
>> [5] base ::= '@'? [Bb][Aa][Ss][Ee] IRIREF "."?
>>
>
> Technical issues discussed in a separate reply.
>

Yeah, ran into all that as started testing.


>
>
>> Cheers,
>> Gavin
>>
>
> Please make the questionnaire and results public.
>

+1 Is there any reason they aren't? It seems very poor given the amount of
feedback on this issue from people outside the working group.


>
>         Andy [*]
>
> Disclosure:
>
> [*] My vote in the poll:
> Slight preference for disallowing PREFIX and BASE
>
> Comment: [[
> The comments list unscientifically suggests more "against" than "for".
> ]]
>
> PS The proposal for
>
> > [4] prefixID ::= '@'? [Pp][Rr][Ee][Ff][Ii][Xx] PNAME_NS IRIREF "."?
> > [5] base ::= '@'? [Bb][Aa][Ss][Ee] IRIREF "."?
>
> also asked for 'a' to be case-insensitive.
>

PS. So did proposal #1 of this email ;) We can all pretend that didn't
happen