Lists Home |
Date Index |
- To: "Jonathan Borden" <email@example.com>
- Subject: URIs, Names, QNames (RE: [xml-dev] misprocessing namespaces (was Re: [xml-dev] There is a meaning, but it's not in the data alone))
- From: "Manos Batsis" <firstname.lastname@example.org>
- Date: Thu, 31 Jan 2002 11:03:37 +0200
- Cc: <email@example.com>
- Thread-index: AcGp0/ZP1rG/QJ74Tly1ZIUffDt1LQAXiANg
- Thread-topic: URIs, Names, QNames (RE: [xml-dev] misprocessing namespaces (was Re: [xml-dev] There is a meaning, but it's not in the data alone))
> -----Original Message-----
> From: Jonathan Borden [mailto:firstname.lastname@example.org]
> 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
BTW I would love being able to declare namespaces as:
<!--OR xmlns:ns1.1.1="#XPointer(id('typeName')])" -->
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.