qname shortland starting with a digit

[lup]

Hi,

For the following uri <http://tap.xmlns.com/data/7UpBrand>

A n3 file can contains:

    @prefix data: <http://tap.xmlns.com/data/>
    :x a data:7UpBrand

The n3 grammar do not accept "data:7UpBrand"

I propose to change qname non terminal definition as follow:

[qname] : name
        | ':' n_name_opt
        | name ':' n_name_opt
        ;

n_name_opt :
           | n_name
           ;

where n_name is a name that can start with a digit

Luc Peuvrier

[timrdf]

Luc,

Sesame 2.2.4 does not handle digits at the start of the local part of a QName, either. (Perhaps 3.0b does, but I haven't found the time)

Jena 2.5.4 and Jena 2.6.0 do, however.

Rather annoying behavior. I heard claims of "Historic XML namespace QName compliance", but Saxon handles elements with "digit names" in Plain Old XML....

Does anyone know why tools are mixed on how they handled digits in QNames? I would imagine that it would be a natural desire.

Regards,
Tim Lebo

On Mon, Apr 27, 2009 at 5:49 AM, luc peuvrier at home <lc.pvrr@...> wrote:

Hi,

For the following uri <http://tap.xmlns.com/data/7UpBrand>

A n3 file can contains:

  @prefix data: <http://tap.xmlns.com/data/>
  :x a data:7UpBrand

The n3 grammar do not accept "data:7UpBrand"

I propose to change qname non terminal definition as follow:

[qname] : name       | ':' n_name_opt
      | name ':' n_name_opt
      ;

n_name_opt :
         | n_name
         ;

where n_name is a name that can start with a digit

Luc Peuvrier

[Seaborne, Andy]

Tim rdf wrote:
> Luc,
>
> Sesame 2.2.4 does not handle digits at the start of the local part of a QName, either. (Perhaps 3.0b does, but I haven't found the time)
>
> Jena 2.5.4 and Jena 2.6.0 do, however.
>
> Rather annoying behavior. I heard claims of "Historic XML namespace QName compliance", but Saxon handles elements with "digit names" in Plain Old XML....
>
> Does anyone know why tools are mixed on how they handled digits in QNames? I would imagine that it would be a natural desire.


The Jena reader is adhering to the principle of being permissive in what
it accepts.  The Jena readers for Turtle are derived from SPARQL where
the local part of a prefixed name does allow a digit as the start char.

QNames (as in the XML Namespaces concept) do not allow the local part to
start with digit.  SPARQL does not call it's abbreviations "qnames".

Turtle submission:
"""
10. Turtle compared to SPARQL
...
# SPARQL allows '.'s in names in all positions apart from the first or last.
# SPARQL allows digits in the first character of the PN_LOCAL lexical
token. In Turtle, the only ascii characters allowed in a nameStartChar
are [A-Z] | "_" | [a-z].
"""

SPARQL changed to allow the leading digits in the local part during the
time of the original working group based on quite a lot of user input.

I don't know of any reason not to accept digits at the start of the
local part.  For URIs derived from other naming schemes, it comes up
naturally and forcing full forms <>, or strange prefix choices, adds no
value.

        Andy

>
> Regards,
> Tim Lebo
>
> On Mon, Apr 27, 2009 at 5:49 AM, luc peuvrier at home <lc.pvrr@...<mailto:lc.pvrr@...>> wrote:
> Hi,
>
> For the following uri <http://tap.xmlns.com/data/7UpBrand>
>
> A n3 file can contains:
>
>   @prefix data: <http://tap.xmlns.com/data/>
>   :x a data:7UpBrand
>
> The n3 grammar do not accept "data:7UpBrand"
>
> I propose to change qname non terminal definition as follow:
>
> [qname] : name       | ':' n_name_opt
>       | name ':' n_name_opt
>       ;
>
> n_name_opt :
>          | n_name
>          ;
>
> where n_name is a name that can start with a digit
>
> Luc Peuvrier
>
>
>
>

[timrdf]

Andy,

Thanks for the information.

Looks like SPARQL made some very convenient decisions. Thanks, WG!

-Tim Lebo

On Mon, Jun 29, 2009 at 1:18 PM, Andy Seaborne <andy.seaborne@...> wrote:

Tim rdf wrote:

Luc,

Sesame 2.2.4 does not handle digits at the start of the local part of a QName, either. (Perhaps 3.0b does, but I haven't found the time)

Jena 2.5.4 and Jena 2.6.0 do, however.

Rather annoying behavior. I heard claims of "Historic XML namespace QName compliance", but Saxon handles elements with "digit names" in Plain Old XML....

Does anyone know why tools are mixed on how they handled digits in QNames? I would imagine that it would be a natural desire.

The Jena reader is adhering to the principle of being permissive in what it accepts.  The Jena readers for Turtle are derived from SPARQL where the local part of a prefixed name does allow a digit as the start char.

QNames (as in the XML Namespaces concept) do not allow the local part to start with digit.  SPARQL does not call it's abbreviations "qnames".

Turtle submission:
"""
10. Turtle compared to SPARQL
...
# SPARQL allows '.'s in names in all positions apart from the first or last.
# SPARQL allows digits in the first character of the PN_LOCAL lexical token. In Turtle, the only ascii characters allowed in a nameStartChar are [A-Z] | "_" | [a-z].
"""

SPARQL changed to allow the leading digits in the local part during the time of the original working group based on quite a lot of user input.

I don't know of any reason not to accept digits at the start of the local part.  For URIs derived from other naming schemes, it comes up naturally and forcing full forms <>, or strange prefix choices, adds no value.

       Andy

Regards,
Tim Lebo

On Mon, Apr 27, 2009 at 5:49 AM, luc peuvrier at home <lc.pvrr@...<mailto:lc.pvrr@...>> wrote:
Hi,

For the following uri <http://tap.xmlns.com/data/7UpBrand>

A n3 file can contains:

 @prefix data: <http://tap.xmlns.com/data/>
 :x a data:7UpBrand

The n3 grammar do not accept "data:7UpBrand"

I propose to change qname non terminal definition as follow:

[qname] : name       | ':' n_name_opt
     | name ':' n_name_opt
     ;

n_name_opt :
        | n_name
        ;

where n_name is a name that can start with a digit

Luc Peuvrier