[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: misprocessing namespaces (was Re: There is a mea

• To: "Mike Champion" <mc@x...>, "The Deviants" <xml-dev@l...>
• Subject: Re: misprocessing namespaces (was Re: There is a meaning, but it's not in the data alone)
• From: "Jonathan Borden" <jborden@m...>
• Date: Wed, 30 Jan 2002 16:12:13 -0500
• References: <NLV87ECHQ4Y1XRSQRPGCZXVPONDA.3c5832c7@MChamp>

Mike Champion wrote:

> 1/30/2002 1:02:33 PM, "Simon St.Laurent" <simonstl@s...>
> wrote:
>
> >Weirder, actually. Like:
> ><test http://foo.com/bar/baz="value" />
>
> What's weird about that (other than the http:// ...and all the
> baggage that drags along with it)?  I thought terseness was not a
> consideration for XML?
>
> There was a long, long sml-dev thread on this horrid subject, and the
> conclusion (as I recall) that simply putting the full domain
> qualifier in the markup vocabulary was the cleanest solution for
> everyone concerned (except the typist).
>

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.

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.

Jonathan

• Follow-Ups:
  • Re: misprocessing namespaces (was Re: There is ameaning, but it's not in the data alone)
    • From: Mike Champion <mc@x...>

• References:
  • Re: misprocessing namespaces (was Re: There is ameaning, but it's not in the data alone)
    • From: Mike Champion <mc@x...>

• Prev by Date: Re: QNames in attribute values
• Next by Date: RE: misprocessing namespaces (was Re: There is a meaning, but it's not in the data alone)
• Previous by thread: Re: misprocessing namespaces (was Re: There is ameaning, but it's not in the data alone)
• Next by thread: Re: misprocessing namespaces (was Re: There is ameaning, but it's not in the data alone)
• Index(es):
  • Date
  • Thread