OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] RDDL (was RE: [xml-dev] Negotiate Out The Noise)

[ Lists Home | Date Index | Thread Index ]


Thank you for the article. It does not affect the points I made.
See below.

----- Original Message -----
From: "Leigh Dodds" <ldodds@ingenta.com>

> > (When looking at RDDL file itself,
> > note verbosity and cut&paste - not because
> > the author is a moron. It is because of RDDL design.
> > Beloved W3C's style )
> Hmmm. RDDL consists of exactly one new element which
> has a handful of xlink attributes, not all of which are
> required. How's this verbose?

     xlink:title="The PizzaML XML Schema">

      The XML Schema for PizzaML documents is
      <a href="http://www.bath.ac.uk/~ccslrd/examples/pizzaml/schema.xsd";>
     available from here</a>.


> Or are you claiming that XHTML is verbose?

No, I'm saying that you are cutting and pasting the same
URL twice ( and you actually should do one
more cut & paste for that URL, like Elliotte Rusty
Harold does. See his example )

I avoid cut & paste at all costs because it is a root
of all evil. This particular cut&paste can be fixed, BTW.

> > It is obvious for me that RDDL is a joke. Like it is
> > possible to have just one XSLT stylesheet for all
> > recipes!
> I included an example in my tutorial that demonstrates
> having several XSLT stylesheets linked from one RDDL
> document.
> For XSLT, use the xlink:arcrole attribute to indicate the
> namespace of the resulting document.

Here is your code you're talking about. ( BTW - note cut & paste again )
and it is orthogonal to 'receipe' example  I was talking
about. Yes, your example makes better advertisement for RDDL,
but I think that Elliotte's is still more generic. It would be nice
to see how can 'receipe' usecase benefit from that 'arcrole' thing.

Back to your example.


   xlink:title="Transform Pizza Menu to XHTML">
<!-- ... -->


   xlink:title="Transform Pizza Menu to RSS">
<!-- ... -->


   xlink:title="The PizzaML DTD">
<!-- ... -->

   xlink:title="The PizzaML XML Schema">
<!-- ... -->

> > **********
> > The whole idea of namespaces was to support the
> > *mixes* of 'receipes' with 'something else'
> > **********
> >
> > RDDL is plain working *against* the original goal.
> No. No problems with the assertion, just the wrong
> conclusion.

Why the conclusion is wrong?

"Just call your purpose 'arcrole' "... For the
reasons that are too coplex to underestand,
right? Why should I call *purpose* *arcrole*,
if it is *purpose* ? Typical W3C again. And
you call it 'simple'.  But see below.

Purpose (xlink:arcrole)
The xlink:arcrole attribute describes the purpose of our resource. It is
harder to determine a purpose than to determine a type, so RDDL defines a
number of common purposes. In general the purpose of a resource is dependent
on its nature.

Our example above provides several examples. The purpose of the PizzaML Menu
stylesheet is the XHTML namespace, which indicates that this is an XSLT
stylesheet that generates XHTML. Yet the PizzaML DTD is to be used for
validation and so is labeled with the special RDDL validation purpose. It's
important to note that RDDL differentiates between DTD and Schema-based
validation, as the example clearly demonstrates.

There isn't space to discuss all the potential purposes of RDDL resources,
but the initial list of well-known purposes provides many more examples. As
with natures, this list will expand over time.

It should be clear from the example that, using nature and purpose together,
it's possible to distinguish between two resources of the same type. Such
distinction allows an application to define the type of resource it wishes
to retrieve. A person can directly browse the RDDL document to determine the
resource that he or she requires


> RDDL associates resources with namespaces, it doesn't
> have anything to say about documents with multiple
> namespaces -- although you can still retrieve resources
> (or read documentation ) for those namespaces if there's
> an associated RDDL document.

That is what I'm saying. In the case of multiple namespaces
in your document all the support that you have from RDDL
is a link to HTML page describing a set of tags. Let me repeat
myself : the idea of Namespaces was to have *multiple*
Namespaces in your document. If you have only a single
Namespace - you don't need no Namespaces! I think if you
would not ignore what I'm writing that would make this thread
more productive. Answering only to parts of my arguments
enforces me to write the ignored arguments again.

OK sombody now may say that "no, namespaces are not for
that". Gosh, that Namespaces thread has no end.

> It neither mandates single namespace documents, nor
> causes any difficulties when working with multiple namespace documents.
> So it is not working against the goal of the Namespace REC.
> > Current RDDL is a misleading paper...
> What precisely is misleading? I found the spec very simple and
> elegant, I didn't notice any sleight-of-hand.

Well, maybe it is misleading because it calls
'purpose'  - 'arcrole' ? Maybe it has way too
much extra tags and dumb cut&paste, because
RDDL just fails to see a simple way, how can one
add the metadata to ... the ... URL ?

The answer is : with the attribute hook. with
CSS style - whatever. *Anything* but cut&paste
can work, but because RDDL guys need to
masquerade what they *really* do
( 'add a bunch of weird URLs to HTML page' ) ,
they *can not* see the trivial solutions, but they
are blinded by those 'natures', 'arcroles' e t.c.

Maybe it is misleading because it contradicts the
basic idea of Namespaces, but somehow
assumes that Namespaces are *not* for 'mixes'
but ... wait a minute ... what the heck is Namespace?
It is "a handy way to attach an HTML documentation
to set of tags"? HAHAHAHA. That's so funny.
HAHAHAHA. I told you - RDDL is a joke.
It is a very nice joke that a few people can see.

Maybe it is misleading because instead of saying :
"guys, we just allow you to plug some
funny URLs that do not look like URLs -
into your HTML homepages" it  talks about
'purposes', 'natures' and 'roles' ?

If it is a crazy URL, make it look like a
crazy URL, damn it.

RDDL is to add some questionable URLs
that do not look like URLs to the HTML files.


Well, if we 'let computers to browse the web',
we sure need some better linking  than good old
A HREF that we have out there, unfortunately

RDDL is not an example of clear design for that.

> > 'Appropriate' stylesheet is a  very questionable entity.
> > There is no 'appropriate' stylsheet that fits all
> > possible 'future' situations for some 'tag'.
> No argument there.  'Appropriate' could be defined as
> "I need a stylesheet to turn vocab X into vocab Y, is
> there an stylesheet in the directory with an arcrole for vocab
> Y'. If there is, I can use it. Excellent, RDDL has brought me
> some real benefits. If it there isn't, then RDDL hasn't cost me
> anything.

That's such an ... argument ... XML people are using
all the time : "if you don't like it - just don't use"

Sure I would not use RDDL and I explained why I would
not use it. That's explained in my letters. That was
the point of my letters (even it originally was not the point,
I was enforced to talk about this RDDL thing).

What is *excellent* in RDDL  - I don't udnerstand and
I would never understand.

> >... Locating Schema would give almost nothing,
> No, it'll give you the schema.

And my original letter explains  ( and this one repeats )
that "Single True Schema" means : "no need in namespaces".
I would greatly appreciate if people would try
to understand what I'm talking about and ask the
questions, when something is not clear, not just skip it.

> > So what we need is to find some documentation about some
> > set of tags? Just publish the human readable document at the
> > end of namespace URI ;-)
> Fine. But if you want to make some machine readable resources
> available, where should you put them? Why not drop a rddl:resource
> element into your documentation. How hard is that?

Now we are back on really important issue ( covered
in my letter #2, at the beginning of the thread
"Negotiate Out of the Noise")

When machines would start reading my documentation,
then we should talk. Nothing is 'hard', but I am *really*
impressed that all the users of RDDL are spending their time,
writing rddl:resource tags for *computers* that would
*read their pages* in the situation, when *no* computer
*is* reading their pages!

I see it as a religious sacrifice. I'm serious. They are writing
their 'rddl' tags ( which are not a minute to write and
maintaining URLs is a pain, actually ) and *nobody* reads those
rddl tags, but True Belivers of Holy RDDL belive that *some day*
somebody would write a "blessed RDDL robot" that would
start reading their rddl tags.

I would like to repeat one of my recent letters. I can
write *much* better ( dfistributed ) RDDL, but the problem
that I see is : where are people and what are projects that
would benefit from 'RDDL' ?

If somebody is using ( or was thinking about using ) current
RDDL for the *particular* purposes other than
religious sacrifies - pelase, please, please - contact me immediately,
I would implement *way* better open-source thing for you.
For free. ( See below ).

> > In my opinion, RDDL is a joke. For 'human' - who
> > cares about anything better, than HTML page?
> And that's effectively what they get when they look
> at a RDDL document.

Yes. RDDL is an HTML page with weird URLs
which  don't look like URLs.

I imagine people writing A HREFs before the
first HTML browser would exist. How would
we call them? Religious fanatics, I guess.

> > The *real* problem is how to make
> > *computers* to cooperate with each other,
> > in a sense, that my computer 'cooperates' with
> > some computer in Macromedia, when MS IE
> > fetches the Macromedia plugin, when
> > encountering an 'unknown tag'.
> Here I disagree, what if I want to use a different
> implementation of a plug-in. If the browser were RDDL
> aware it could present me with some choices.

Oh, let us stop here. If we want to design some real stuff,
we can do that, but we should not do that in the
thread with subject RDDL. ( And the first question
I would ask would be : "OK, I can give you whatever
API you want - for free. Just tell me the real-life project
that you're doing *right now* and that you would
keep doing for some time in a future, that could
benefit from this 'RDDL', because I am thinking about
this stuff for one year and I'm talking to people about this
stuff for one year and there are real problems with this
problem domain. The lack of 'real tasks' is one of these
problems and to me it looks most important one".)

*That* would be the first step. Not "what can we place
at the end of Namespace URI?" ( Which is pretty religious
question. In the middle ages they were discussing that stuff
about the daemons and the needle ... Religion is fun. History
is funny. )

> >The problem, which is 'solved' by RDDL
> >is too hypothetical to be of a serious value
> >and as a bonus it contradicts the basic design
> >idea of  'namespaces'!
> I find this assertion to be ironic, seeing as RDDL itself
> makes good use of multiple namespaces to achieve it's
> goals.

OMG. Achive it's religious goals? Could be. I do not
belive in a holy computer that would some day start
reading  my rddl tags. When I'l see how can I
use that holy computer - I think I'l manage how to
write the tags for it.

WWW has been started when TBL tried to solve
a *particular* task. Not with the holy sacrifice.
The detailes are in the Book "Weaving the Web".

> > No more letters from me on RDDL.  Some people
> > use it. This is fine, but when I've used the word RDDL,
> > I was *not* talking about current RDDL ( neither was
> > Len talking about current RDF, I think ), I'm very sorry
> > to use the RDDL buzzword and I would try never use
> > it again.
> Fine, but I'm responding anyway, so the archives contain
> a more objective viewpoint.

And I had to make a summary of all my letters
on this subject to show that RDDL is a joke and
people just don't see it, even after writing an article
about it. I don't see why your viewpoint is more
objective than mine,  I think you call your point
objective because you did not understand my
points and I hope that this letter would make
a nice summary of my position on 'RDDL'.

Sorry if something was disturbing, but as an excuse
I should say that there is not a single point in this
summary letter that never appeared in my previous
letters. I just re-collected and repeated all the points
that are *already* in the thread with the subject
"Negotiate Out the Noise". Because of that,
in the future, I would not answer to any question
about RDDL which is already in this thread,
no matter how you would call my point  of view.

I wish I'm done with this RDDL Ghost because
all the answers that I can give are in the thread
"Negotiate Out the Noise" and in this letter.


PS. I think it is now obvious that it is mostly
religious stuff with RDDL. Len just said a
magic word - I answered with another magic
word and - bang! The daemons are flying around
and smart people are blinded and can not see
cut&paste in  a few lines of their own HTML code.
That's a real magic of XML.


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS