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 21:00:06 +0100
Message-ID: <93DD0D20-3310-4FF7-8C89-D6C28D02C05F@S009>
To: "'Misha Wolf'" <Misha.Wolf@reuters.com>
Cc: <public-rdf-in-xhtml-tf@w3.org>, <iptc-metadata@yahoogroups.com>
Hi Misha,
 
> Would you still envisage using regular namespace declarations?

That was what I was thinking -- that the prefix plus ':' is simply replaced
with the real namespace, in something like a string substitution. There are
many places you see this type of thing, from Apache configuration files, to
Mozilla prefixes for accessing Google. I think it's something that people
would probably understand quite easily. (Whilst they probably wouldn't
understand that there are certain QNames that are not valid for creating
URIs.)

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/ 

 



________________________________

	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 16:39
	To: Mark Birbeck
	Cc: public-rdf-in-xhtml-tf@w3.org; iptc-metadata@yahoogroups.com
	Subject: RE: Potential new TAG issue: Numeric LocalPart of QName
held in attribute value
	
	
	Hi Mark,
	 
	That's an interesting idea.  There's a tension between:
	 
	-  using QNames for this purpose, as they are an established part of
the scenery
	 
	-  not using QNames for this purpose, as they were designed for a
different purpose (element/attribute names) and the two purposes bring along
differing requirements
	 
	From the examples you give, am I right in imagining that other
groups might find such an approach useful?
	 
	Would you still envisage using regular namespace declarations?
	 
	Misha

________________________________

	From: public-rdf-in-xhtml-tf-request@w3.org
[mailto:public-rdf-in-xhtml-tf-request@w3.org] On Behalf Of Mark Birbeck
	Sent: 19 July 2005 16:30
	To: Misha Wolf
	Cc: public-rdf-in-xhtml-tf@w3.org; iptc-metadata@yahoogroups.com
	Subject: RE: Potential new TAG issue: Numeric LocalPart of QName
held in attribute value
	
	

	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. 
	> 
	> 
	> 

	
	
	-----------------------------------------------------------------
	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 20:01:01 GMT

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