[Home] [By Thread] [By Date] [Recent Entries]
> -----Original Message----- > From: Jonathan Borden [mailto:jborden@m...] > 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('typeName')])" --> </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
|

Cart



