W3C home > Mailing lists > Public > public-rdf-in-xhtml-tf@w3.org > July 2005

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

From: Mark Birbeck <mark.birbeck@x-port.net>
Date: Tue, 19 Jul 2005 16:29:31 +0100
Message-ID: <D8096A59-DA78-4409-9C3B-9F48E7EB29A6@S009>
To: "'Misha Wolf'" <Misha.Wolf@reuters.com>
Cc: <public-rdf-in-xhtml-tf@w3.org>, <iptc-metadata@yahoogroups.com>
Hi Misha,

I had been thinking about this after you explained it to me, and I was going
to suggest that actually we don't try to change 'QName' but instead
introduce a new type, called something like 'extended QName' or 'compact
URI', or something. (EQName or CompURI, or whatever.)

I suggest this, because the problem you describe is not a problem of QNames.
They actually need to stay in sync with element names, since that is the
reason they are defined they way they are, in the XML and Namespaces spec.
(Of course you could campaign for the rules of element names to change, but
that might take you a few years!)

The 'real' problem (if you don't mind me saying ... ;) ) is that a
convention has arisen that a QName is a convenient packaging mechanism for a
URI. However, as you have discovered this convention falls short, since
QNames cannot express every URI.

A 'compact URI' syntax would simply require a new schema type in its host
language, and some processing rules -- I don't believe that it would need
dramatic changes in other W3C specifications.

Note that allowing the naming rules for the local part to not have to
conform to the rules for an element name allows not only the syntax that you
need:

  iptc:11000188
  isbn:1344567

but could also provide us with:

  home:#start
  joseki:
  google:xforms or 'xml forms'

Some people might say that the syntax should not look like QNames, but I
would disagree; all QNames are still 'compact URIs', but of course, not all
'compact URIs' are QNames.

Regards,

Mark


Mark Birbeck
CEO
x-port.net Ltd.

e: Mark.Birbeck@x-port.net
t: +44 (0) 20 7689 9232
w: http://www.formsPlayer.com/
b: http://internet-apps.blogspot.com/

Download our XForms processor from
http://www.formsPlayer.com/ 

> -----Original Message-----
> From: public-rdf-in-xhtml-tf-request@w3.org 
> [mailto:public-rdf-in-xhtml-tf-request@w3.org] On Behalf Of Misha Wolf
> Sent: 19 July 2005 15:06
> To: public-rdf-in-xhtml-tf@w3.org; iptc-metadata@yahoogroups.com
> Subject: FW: Potential new TAG issue: Numeric LocalPart of 
> QName held in attribute value
> 
> 
> fyi
> 
> 
> -----Original Message-----
> From: Misha Wolf
> Sent: 19 July 2005 15:05
> To: www-tag@w3.org
> Subject: Potential new TAG issue: Numeric LocalPart of QName 
> held in attribute value
> 
> The International Press Telecommunications Council (IPTC) [1] 
> is developing a comprehensive News Architecture [2], which 
> will serve as the foundation for all new IPTC Standards and 
> for new major versions of existing IPTC Standards.  The IPTC 
> News Metadata Framework WG has decided that:
> 
> -  URIs will be used to identify all resources, including terms used 
>    as News metadata.
> 
> -  If at all possible, these resources will form part of the Semantic
>    Web.
> 
> Owing to:
> 
> -  the large amount of metadata that may be present in a News object,
> 
> -  the need for compactness,
> 
> -  and the need for legibility
> 
> the WG has decided to use QNames in attribute values to 
> represent terms used as News metadata.  We are working 
> closely with the W3C RDF-in-XHTML Task Force on this and 
> related issues.  During a recent meeting, a glitch came to 
> light, which is the reason for this mail.
> The glitch is that:
> 
> a)  many News-related taxonomies use numeric codes, including:
>     -  IPTC NewsCodes for Subjects [3]
>     -  the Global Industry Classification Standard (GICS(r)) [4]
>     -  the Industry Classification Benchmark (ICB) [5]
>     -  the North American Industry Classification System (NAICS) [6]
> 
> b)  the Namespaces in XML specification states that:
>     -  the LocalPart of a QName is an NCName
>     -  the first char of an NCName is an NCNameStartChar
>     -  an NCNameStartChar is any NameStartChar other than a colon
> 
> c)  the XML specification states that a NameStartChar cannot be a 
>     digit
> 
> What are the options?  The only one we can think of right now 
> is to request that this constraint on the first char of a 
> LocalPart be lifted if the QName is held in an attribute value.
> 
> I considered approaching the XML Core and XML Schema WGs, but 
> as this matter may be of broader interest, I am writing in 
> the first instance to the TAG.
> 
> [1] http://www.iptc.org/
> [2] http://www.iptc.org/dev/
> [3] http://www.iptc.org/NewsCodes/
> [4] http://www.gics.standardandpoors.com/
> [5] http://www.icbenchmark.com/
> [6] http://www.census.gov/epcd/www/naics.html
> 
> Misha Wolf
> Standards Manager, Reuters
> Chair, IPTC News Metadata Framework WG
> 
> 
> 
> -----------------------------------------------------------------
>         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 15:30:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:15:00 GMT