W3C home > Mailing lists > Public > www-tag@w3.org > July 2005

RE: Potential new TAG issue: Numeric LocalPart of QName held inattribute value

From: Misha Wolf <Misha.Wolf@reuters.com>
Date: Tue, 19 Jul 2005 15:34:48 +0100
To: www-tag@w3.org
Message-id: <1987416CA83AC7499AC772F92E2DBF7804290F94@LONSMSXM02.emea.ime.reuters.com>

Dan Connolly wrote:

On Tue, 2005-07-19 at 15:05 +0100, Misha Wolf wrote:
> [...]
> > the WG has decided to use QNames in attribute values to represent
> > terms used as News metadata.
> 
> I don't endorse that decision, but...
> 
> > c)  the XML specification states that a NameStartChar cannot be a 
> >     digit
> > 
> > What are the options?
> 
> I have run into this situation of wanting to use an integer
> as an XML name. I prepend an underscore.
> 
>  rdf:ID="_1232"
> 
> works pretty good.

We have considered this approach but are concerned that masses of
software expect, say, the GICS code for Oil & Gas Exploration & 
Production to be "10102020".  If we tell people to use "_10102020" 
instead, we are likely to give such software indigestion.

> p.s. I don't really understand how this might be a new TAG issue.
> It seems like a pretty low level XML syntax issue.

Owing to the growing use of QNames for this purpose, it would be good
to have an agreed approach, rather than everyone doing their own 
thing.  As the contraint was designed for a different case (ie for 
element/attribute names) it is worth at least considering relaxing it
for the attribute value case.  I wanted to test the water with the 
TAG, before approaching the W3C WGs that own these specifications.

Misha



-----------------------------------------------------------------
        Visit our Internet site at http://www.reuters.com

To find out more about Reuters Products and Services visit http://www.reuters.com/productinfo 

Any views expressed in this message are those of  the  individual
sender,  except  where  the sender specifically states them to be
the views of Reuters Ltd.
Received on Tuesday, 19 July 2005 14:35:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:09 UTC