cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From solprovi...@apache.org
Subject Re: Can't match elements with colons
Date Mon, 14 Jul 2008 16:24:53 GMT
On 7/14/08, netBrackets <jeffandmonica@mac.com> wrote:
> When defining OWL models, the # in the URI (FWIW, in OWL it's considered a URI and not
a URL) separates the URI of the model with the thing being referenced that exists within the
model.  However, out of habit, I was using the # when defining a namespace that had nothing
to do with an OWL model, so I think it was really my error.

Mostly off-topic:
The examples use URLs. Using URNs would be very useful if some
directory handled the translation.  Since no central directory of DTDs
is recognized, XML namespace declarations must use URLs.  OWL belongs
to the Semantic Web movement that would like to create central
directories.  The advantage of using URIs rather than the URL subset
is to allow URNs when feasible.  Programmers should write code
accepting URNs while understanding that URLs will remain the only
useful identifier except in limited controlled scenarios.

URI is the category name for all content identifiers while URLs are
specific to network locations.  Referring to URIs while requiring URLs
is like referring to vehicles when the discussion is limited to muscle
cars -- statements are technically accurate, but less specific than
sane people expect.  The W3C specification for namespace declaration
allows non-relative URIs, but all examples are URLs for the reasons in
the first paragraph.

A problem with the W3C's specification for namespace declaration is
the results are not normalized.  "http://example.com",
"http://example.com/", "http://example.com:80/", and
"http://example.com/#" are treated as distinct identifiers.  Everyone
and every application should parse all these URLs to {scheme="http",
server="example.com", port="80", path="/", anchor=""} so giving any
two of these strings to an equality function returns true.  The W3C
and your XSL processor ignore this reality.

This would be a rant if I cared, but my perspective is these issues
are mostly entertainment.  You were unlucky to discover a situation
where committee-driven silliness affects a real-world implementation.

solprovider

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message