- From: Misha Wolf <Misha.Wolf@reuters.com>
- Date: Tue, 19 Jul 2005 16:39:15 +0100
- To: Mark Birbeck <mark.birbeck@x-port.net>
- Cc: public-rdf-in-xhtml-tf@w3.org, iptc-metadata@yahoogroups.com
- Message-ID: <T723c28786c0a01f01c16b4@lonsmime04.rit.reuters.com>
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 15:39:31 UTC