Re: extraneous :'s?

[email protected] Fri, 8 Dec 2006 16:23:19 -0800 (PST)
Newsgroups gmane.lisp.scheme.ssax-sxml
Message-ID <[email protected]>
Jonathan A Rees wrote:

> <rdf:RDF xmlns:rdf='http://www.w3.org/1999/02/22-rdf-syntax-ns#'
> 	 xmlns:x="http://mumble.net/">
>    <x:thing>
>       <x:verb resource="http://mumble.net/thing" />
>    </x:thing>
> </rdf:RDF>
>
> (call-with-input-file "loser.rdf"
>         (lambda (in) (ssax:xml->sxml in '()))))
>    =>
> (*top* (http://www.w3.org/1999/02/22-rdf-syntax-ns#:RDF
>           (http://mumble.net/:thing
>             (http://mumble.net/:verb
>               (@ (resource "http://mumble.net/thing"))))))
>
> My understanding of Qnames is that the namespace prefix is  
> concatenated with the name part of the Qname. The : as far as I know  
> is idiosyncratic to the SXML specification. In the case of rdf/xml  
> this makes a difference, since anyone processing the above rdf/xml  
> will want the URI representing the x:thing Qname to be the same  
> string as the value of the resource= attribute.

I'd like to point out confusion first: between QNames (qualified
names) and expanded names. The definitions of both are given in
Section 2.1 of the W3C Recommendation `Namespaces in XML 1.0 (Second
edition)'. In short, QNames appear in an XML document. An expanded
name is what QNames are mapped to after parsing and namespace
processing. That is, an application only sees expanded names. In the
example above: ``x:thing'' is a QName. To be precise, it is a prefixed
QName. The colon is _mandatory_: see the productions [7-11] of Section
4 of the XML Namespace Recommendation, in particular, production [8].

> Is concatenation strictly required by XML? E.g. if you write
> xmlns:foo=abc and xmlns:bar=abcde, are the Qnames foo:defg and bar:fg
> *required* to be considered interchangeable?

Certainly not. foo:defg and bar:fg are different QNames because they
have different prefixes and different local parts.

Already XML validation is done in terms of _expanded_ names rather
than in terms of QNames. Section 6.3 of the XML Namespace
Recommendation shows the example of violation of the uniqueness of
attributes constraint. Two attributes with different QNames happen to
have the same expanded name, and so cannot both appear as attributes
of an element. More details on what an application can expect to see
as the result of XML parsing is described in the XML Information set
(W3C Recommendation); see, for example, Section 2.2.

Thus, QName is what appears in the source XML document. An application
does _not_ get to see that. An expanded name is an abstract data type,
the result of parsing a QName. An expanded name has two accessors,
that give the namespace name (URI, as a string) and a local
part. Separately. Two expanded names are considered equal if their
namespaces (namespace URI) are equal strings, and, separately, their
local names are identical. 

SXML chose a particular realization of the abstract data type of
expanded names. The realization takes advantage of the fact that the
local part may not contain colon. Thus, given an SXML symbol such as
http://mumble.net/:verb we can always recover the namespace URI part
and the local part. Also, the comparison of SXML symbols (when
properly internalized, as SSAX parser does) satisfies the
specification for the comparison of expanded names.

Doug Orleans wrote:
> It seems like it would be easier if SXML stored expanded names as
> actual cons pairs, though.

That is a valid design choice. The traversal of SXML documents would
have been more complex though: when the pre-post-order combinator sees
a pair '(x . something), the combinator can't tell what exactly this
thing is: either this is an XML element (and so something is '() or a
list) or it is an expanded name (in which case something is a
symbol). So, we need to look ahead. Another valid design choice for
representing expanded names is a record. Alas, records are not
standard in R5RS.

	Cheers,
	Oleg

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV