URIs, Names, QNames (RE: [xml-dev] misprocessing namespaces (was Re: [xml-dev] There is a meaning, but it's not in the data alone))

["Manos Batsis" <m.batsis@bsnet.gr>]

> -----Original Message-----
> From: Jonathan Borden [mailto:jborden@mediaone.net] 


> This thread is great. If you take a look at the RDF activity, 
> you'll see
> syntaxes such as N-triples that provide statements (triples) 
> in their full
> URI format: everything becomes a URI, no need for element or attribute
> names. Well it turns out that this if just fine for software 
> but a real bear
> for humans to read, and so people (specifically the RDF 
> folks) turn back to
> QNames, using QNames as a shorthand for URIs (e.g. RDF/XML 
> and N3). That is
> the same reason for the proliferation of QNames in attribute 
> values (human
> readability) Imagine what an XPath would look like in 
> expanded URI form.

Exactly. An resource can occur as a subject, object or predicate.
Referring to that resource *in* a simple type  (from an XSD point of
view)  leaves you with the choice of a QName or a full URI, witch is
rather messy.

BTW I would love being able to declare namespaces as:

<ns1:root xmlns:ns1="http://www.myOrg.org/ns/2002/"; 
                  xmlns:ns1.1="foo1.xsd" 
                  xmlns:ns1.1.1="#typeName" 
               xmlns:ns1.2="foo.rdf" 
                  xmlns:ns1.2.1="#typeName">

<!--OR xmlns:ns1.1.1="#XPointer(id(&apos;typeName&apos;)])" -->

</ns1:root>

IMHO, the above would have extremely high semantic value, making
automated processing rules easier and scalable. Less headaches too.


> Terseness aside, there is something to be said for human 
> readability, and
> problems with prefixes aside, people are drawn to qnames 
> because they are
> easy to read, especially if you use a well-known prefix.

Fully agreed. I believe that the XML formal considerations about
Terseness and Readability are contradictive at this point.

Kindest regards,

Manos