Cart
[Home] [By Thread] [By Date] [Recent Entries]
----- Original Message ----- From: "Dare Obasanjo" <kpako@y...> > 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.
|
