[
Lists Home |
Date Index |
Thread Index
]
- From: Paul Tchistopolskii <paul@qub.com>
- To: lisarein@finetuning.com
- Date: Sat, 30 Dec 2000 12:25:51 -0800
----- Original Message -----
From: Lisa Rein <lisarein@finetuning.com>
> Paul Tchistopolskii wrote:
>
> > I don't understand. I'm not saying that URIs
> > should be URLs. I'm saying that namespcae URIs
> > should never be dereferenced.
> >
> So you're saying the the namespace URIs shouldn't be allowed to be used
> to connect to XML Schemas to XML documents? Only the dedicated elements
> and attributes that can also serve this purpose?
You are talking about XML Schemas, Sean is talking about RDF. Please
don't miss my letters to Sean - I'm writing some important stuff to him ;-)
I'm saying that vendors should not have a way to use namespaces URIs
for 'linking' functionality in the way not specificed by W3C. Too dangerous.
> Should that functionality be removed from the XML Schema spec then?
> (i don't think that's very likely...)
I think XML Schema will not fly, so I don't care about the paper
you are asking. I also think that RDF will not fly so I don't
care about RDF papers. I care about the wording in Namespaces
spec and clarification of that wording made by Andrew. ;-)
( see beginning of this thread ;-)
> Perhaps I'm just not following you...
I really suggest to re-read the thread from the beginning. If you
are confortable with the fact that all XML books are *wrong*
in their explanation of the namespaces - you are not following me.
To be conformant to current wording of Namespace spec,
every explanation of the Namespaces in those books should
look like : ".... it seems that at some point of time
some tool will start fetching some data from those URIs
and more likely that tool will use URLs for that, so you're
better to make your URI an actual URL. Just in case, you know."
> True, as each of the evil empires (there are several and I'm not naming
> names) decides to implement their URI dereferencing scheme we will all
> just have to deal with all of them, because they will each have an
> instant implementation base.
Imagine the world where XSL will be that belowed subset of XSL
implemented in MS IE XSL.
Would it be a nice world?
Ask somebody who had a chance to compare : using MS XSL was
vaste of time and writing useless cut & paste code.
I'd say that it is better to have no XSL rather than have old MS IE XSL.
> However, I doubt that disallowing its use it until we come across the
> "best" way to do it is going to help anything. The W3C is having a hard
> enough time getting all these core specs out without quibbling over what
> ultimately amount to implementation details (which W3C specs are
> supposed to stay clear of, in theory).
OK, let's explicitely write one more sentence in that Namespaces paper.
"The meaning of the namespace URI is the subject of W3C paper to-be-written
and applications should not use this URI until appropriate W3C paper will
appear"
No problem. It will also close the door.
Current wording is *not* like this. It allows *any* vendor to do whatever
that vendor likes to do in any point of time and be conformant to W3C
specs. It is not 'implementation detail' , you know. It is such a
*huge* 'implementation detail' that I think it is worth saying that :
Nobody should use this hole until W3C make it's mind on the purpose
of namespace URI.
> If you have an innovative method that you feel is better than ToolX's
> hypothetical method, by all means, tell everyone about it, and then
> maybe you can be the de-facto standard (and get bought out by ToolX,
> Inc. :-)
I think you're kidding. In fact, I'm now working on some tools that will
allow some cooperation between 2 documents of different schema
located on one computer. I'l get a practical results in, I think, 2 years.
Then l'l have to map this thing to the Web, that also will take a couple of
years.
I'm working on something that will allow some simple things, like,
you know, asking computer to produce a summary of threads like
this e t.c. No schema, no namespaces, no onthology, no RDF.
Even I'l have my framework *today* - I can not make it a de-facto
standard. Only few companies in the world can abuse that
hole in Namespaces spec. I think it is obvious. The hole in the
standard is very small and only really big company, ( not the
best one, just big one ) can abuse this hole.
I don't like this situation. And I don't understand why others
like sitting on a bomb.
|