Re: Towards a TAG consideration of CURIEs

This looks like an excellent start to me, Henry.  Very well presented, 
relatively factual, balanced, dispassionate, etc.  I was hoping to see 
more of the hard stuff, which is to go beyond framing the issue to take a 
pass at what the answers might be, but on reflection it's probably good to 
have a first pass that just states the question. 

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








ht@inf.ed.ac.uk (Henry S. Thompson)
Sent by: www-tag-request@w3.org
03/30/2007 07:06 AM
 
        To:     www-tag@w3.org
        cc:     (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        Towards a TAG consideration of CURIEs



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I took an action at the last TAG telcon (minutes forthcoming) to try
to draft a statement of where the current CURIE draft [1] (actually
quotes below are from a Member-only editors' draft [1a], which
contains some minor changes to the syntax) raises architectural
issues.

*Executive Summary*

Do the expected benefits of CURIEs outweigh the potential costs in
introducing a _third_ syntax for identifiers into the languages of the
Web?

*Background*

XML Namespaces introduced the notion of expanded names, that is, names
in the form of a pair of namespace name (possibly empty) and local
name.  It further introduced an abbreviation mechanism, involving
prefixes and namespace declarations.  The word 'QName' has come to be
used for both the syntactic form such abbreviations take (i.e.
  (NCName ':')? NCName
) and the two-part name such abbreviations stand for.  As such, QNames
are clearly distinct from URIs.  Their use as identifiers, however,
immediately raises the question of their relationship with URIs.

The TAG considered the use of QNames as shorthand for URIs in issue
rdfmsQnameUriMapping-6 [2], and issued a finding on the the related
subject of using QNames as names for things other than XML elements
and attributes, called "Using Qualified Names (QNames) as Identifiers
in XML Content" [3].

In that finding, we find

  "We observe also that there is an overlap in the lexical space of
   QNames and URIs.

  "Specifications that use QNames to represent {URI, local-name}
   pairs SHOULD NOT allow both forms in attribute values or element
   content where they would be indistinguishable."

and also

   "Where there is a compelling reason to use QNames instead of URIs
    for identification, it is imperative that specifications provide a
    mapping between QNames and URIs, if such a mapping is possible."

The Architecture of the World Wide Web summarises these points in its
section on QNames [4].

*CURIEs*

Unlike QNames, CURIEs are explicitly intended as abbreviations for
URIs.  None-the-less they use an extension of the syntax of QNames,
namely
  NCName ':' [pretty unconstrained string]

*Architectural issues*

If the CURIE WD is eventually adopted, we will have three related
forms of identification:

 1) URIs themselves;
 2) CURIEs as abbreviations of (absolute) URIs;
 3) QNames as abbreviations for expanded names, which in _some_
    circumstances are mapped by convention or explicit algorithm to
    URIs.

In [3] and [4] the potential confusions of overlapping syntax and
function arising from the use of QNames as identifiers and even as
abbreviations for URIs is accepted as a fact with good historical and
pragmatic motivations.

The fundamental architectural question raised by the CURIE
specification is then whether the expected benefits outweigh the
potential costs in introducing a _third_ syntax for identifiers into
the languages of the Web.

A subsidiary question depends on exactly what the intended scope of
application of this specification is -- if it is as widely-targetted
as it appears to be, would it not be better to consider an addendum to
the relevant RFCs, e.g. 3986 and 3987 [5] [6]?

And finally, the question of how CURIE would integrate with the typing
and typed-data manipulation facilities provided by W3C XML Schema and
XPath 2.0/XSLT 2.0/XQuery also needs careful consideration.

ht

[1] http://www.w3.org/TR/2007/WD-curie-20070307/
[1a] http://www.w3.org/MarkUp/Group/2007/ED-curie-20070322/
[2] http://www.w3.org/2001/tag/issues.html?type=1#rdfmsQnameUriMapping-6
[3] http://www.w3.org/2001/tag/doc/qnameids.html
[4] http://www.w3.org/TR/webarch/#xml-qnames
[5] http://www.ietf.org/rfc/rfc3986.txt
[6] http://www.ietf.org/rfc/rfc3987.txt
- -- 
 Henry S. Thompson, HCRC Language Technology Group, University of 
Edinburgh
                     Half-time member of W3C Team
    2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
            Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
                   URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged 
spam]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFGDO8ckjnJixAXWBoRAguVAJ9bRp253y37UMuZwxyTQ07o+60NswCePQpe
1r3jL/PRXK5J7Gaz63u1diA=
=c22I
-----END PGP SIGNATURE-----

Received on Sunday, 1 April 2007 16:01:13 UTC