[
Lists Home |
Date Index |
Thread Index
]
----- Original Message -----
From: "Dare Obasanjo" <kpako@yahoo.com>
> There are two issues I see here. One with which I agree with you
completely
> and another that I think needs to be addressed in more general a manner
than
> 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
should
> be deprecated. Namespaces are meant as a means to namespaces to identify
and
> disambiguate elements and attributes. Confusing the issue by tying these
> namespaces to a web resource is incorrect because it confuses their nature
and
> 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
URI
> in both human readable and machine comprehendable form. Regardless of
whether
> 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
I
> sit, RDDL does not give me this although RDDL is the "Worse is better"
> solution.
Exactly. But it is not 'worse is better'. It is simply 'worse'. Adding one
more
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
out a
> scheme that provides the basic needs raised in ISSUE 2 above without
adding an
> excessive complexity burden on users, authors of XMl documents or parser
> implementors.
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
history.
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 ;-)
Rgds.Paul.
|
