Lists Home |
Date Index |
----- Original Message -----
From: "Dare Obasanjo" <firstname.lastname@example.org>
> There are two issues I see here. One with which I agree with you
> and another that I think needs to be addressed in more general a manner
> RDDL currently does and which I am curious as to your opinions on.
> ISSUE 1: Namespace URIs should not be HTTP URLs and where possible this
> be deprecated. Namespaces are meant as a means to namespaces to identify
> disambiguate elements and attributes. Confusing the issue by tying these
> namespaces to a web resource is incorrect because it confuses their nature
> builds certain expectations in people. Here I agree with you.
Also, as you write below, Namespace may be *not* a URL
and we already have plenty of legacy namespaces which
are *not* URLs.
> ISSUE 2: There should be a way to discover information about a Namespace
> in both human readable and machine comprehendable form. Regardless of
> the namespace URI is "urn:schemas-microsoft-com:datatypes" or
> "http://www.w3.org/1999/XSL/Transform", I'd like to _at_the_very_least_ be
> able to a.) discover the semantics of the elements and attributes in the
> document by looking up the namespace URI and locating a human readable
> document and b.) obtain validation information for the namespace (e.g. the
> XSLT schema or DTD for the XSLT namespace) IF the creator of the namespace
> (right phrase?) has deigned to make such information available. From where
> sit, RDDL does not give me this although RDDL is the "Worse is better"
Exactly. But it is not 'worse is better'. It is simply 'worse'. Adding one
level of indirection solves that. And many other problems as well.
> So is the expectation in ISSUE 2 reasonable or should we continue with the
> message that
> namespaceURI == HTTP URL that may or may not contain
> human or machine readable information.
namespaceURI is a unique hidden property, attached to every tag.
As it is written in a Namespace documentation.
> I hope the answer to the above question is NO and we can eventually work
> scheme that provides the basic needs raised in ISSUE 2 above without
> excessive complexity burden on users, authors of XMl documents or parser
I got tired with this RDDL thread, I think it goes nowhere,
so I decided that instead of repeating the same stuff
over and over again, I would spend some time
implementing the simple alternative to RDDL that would not
abuse any existing XML paper, would not provide any
lock-ins and would work / scale if somebody would
decide to use it.
Not that I'm happy spending time on that ( because I don't use
namespaces ), but I feel that if not doing that, people may
think that they really need these 'arcroles' for something. How
easy it would be to create a mafia around 'my RDDL' -
that's another story.
Give me a few days / weeks (I start working
fulltime next Monday, so I would have only weekend
evenings now) and then I wish this thread would become
I may use HGRAB to steal some stuff from rddl.org, but
because there is no robots.txt - that should be legal thing
to do ;-)
Talk to you later. The existance of open-minded people
in this world is the only thing that protects me from
complete madness ;-)