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 ]


I've just spent some time working back through your 
posts, and the previous discussion to attempt to understand 
where the disagreements are.

It seems that the fundamental point of disagreement is that 
you're asking "what is RDDL for?, what problems does it solve?, 
what applications does it let me build more easily?". And in 
particular you're considering it's applicability to distributed applications 
where some negotiation is required (cf: Lens original thread).

You've asserted that the origins of RDDL are political and not 
technical in nature and that any suggestions as to how RDDL might be 
used in that context are purely scientific. In effect that RDDL is 
a solution to a political problem ("Whats at the end of a Namespace?"), 
and is being used to propose technical solutions in other scenarios.

Here I disagree. RDDL is a solution to a problem that you helped identify, 
and which Mike Champion dubbed the 'Tool X Horror Scenario' [1]. In your 
opinion the loophole that would allow NS URIs to be abused should be closed.
You also argued that it would take 'years' to identify what should be 
put there if anything. Others believed letting it point to a directory of resources 
would meet everyones needs. I don't see any politics involved, just a 
different opinion on the best way to avoid the Horror Scenario.

We can reasonably disagree over whether you see this as a political 
issue. I see RDDL (or an alternative) as more of an interoperability spec, that 
would avoid the creation of ad hoc solutions. As you disagree that this 
is a useful problem to solve, it's not surprising you don't see any 
value in RDDL.

You've also stated that some of us, myself included, have been misleading 
developers by telling them that there's nothing at the end of a NS URI, but 
then turning round and telling them to use RDDL. I still believe the former 
to be the letter of the spec, but believe the latter is required for the 
above reasons. Any claim of 'spy vs spy' is a little insulting.

You've agreed that something *like* RDDL (a way of discovering 
resources) *is* required. But have raised issues about caching, certification, 
etc. There's no disputing that. But this seems to have more 
to do with the resources themselves ("How do I know this Java class 
isn't going to damage my system?") than the directory format. Note that 
it's  also previously been pointed out that RDDL docs could be cached 
locally if one deferences the URI via a Catalog.

As far as concrete feedback on RDDL goes, I see you've made the 
following points:

- rddl:resource and anchors have redundancy, you'd prefer something 
like annotations on the anchor directly. Your rddl-hook attribute.

- that defining something called 'purpose' with an attribute called 'arcrole'
is confusing.

I'm not sure I really do understand your other claims about how RDDL 
interacts with Namespaces. I have a feeling that your saying that a 
single general purpose schema for a namespace isn't useful for 
circumstances where those elements may be mixed freely with others 
from other Namespaces. If so I agree, but I don't see what RDDL 
has to do with this. 

To me it suggests that elements intended to be used in this way should 
not used closed schemas. This is one of the reasons I like Schematron so 



[1]. http://www.xml.com/pub/a/2001/01/10/rddl.html
[2]. http://lists.xml.org/archives/xml-dev/200012/msg00662.html


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

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