[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: On RDDL: cool! some ideas requests for help
- From: Jonathan Borden <email@example.com>
- To: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org
- Date: Thu, 01 Feb 2001 01:01:06 -0500
Dan Connolly wrote:
> RDDL looks pretty cool... I wanna try it out on,
> say, http://www.w3.org/XML/1998/namespace to
> point to stuff like the XML schema we've developed
> for it; it needs an update w.r.t. XML 2nd ed anyway.
> The way the terms in RDDL are grounded
> in URI space is excellent. For example, it facilitates
> translation to RDF. The grounding of MIME types
> in the IANA registry-in-the-web is cool too.
> (I think this approach of using souped-up HTML
> for smart documents is cool; see, for example,
> HyperRDF: Using XHTML Authoring Tools with XSLT to produce RDF Schemas
> Sun, 13 Aug 2000 04:08:38 GMT )
> But I don't see enough examples to make me confident
> that I can do the upgrade of the XHTML document
> currently at http://www.w3.org/XML/1998/namespace conversion
> myself. (or maybe I'm just tired/lazy ;-)
> Anybody wanna tutor me thru it?
I will give it a try.
> By the way... RDDL looks familiar... see:
> HTML Resource element
> Mon, 09 Dec 1996 02:46:45 GMT
> which captures some pre-RDF ramblings on metadata. (if you guys
> knew about that spec when you designed RDDL, please
> acknowledge it with a link.)
I hadn't read it, but that's my fault. Clearly this is strikingly similar to
RDDL (circa 1995) and certainly deserves reference.
> It's cited from
> Web Architecture: Generic Resources
> TBL, 1996, 2000
> Fri, 08 Sep 2000 21:17:54 GMT
> which reminds me... there's a connection to
> HTTP's format negotiation semantics
> that I'd like to see specified. Hm... gotta
> noodle on that...
I've imagined writing an apache mod_rddl or something to that effect that
could server side parse a RDDL and perform content-negotiation (assuming
that there exists a resource nature equivalent to an Accept: content-type.
Even better would be to provide one or both HTTP request headers:
(this could be a general format for server side xlink:role/arcrole
> Another comment... regarding:
> This document defines the syntax and semantics of
> the Resource Directory Description Language,
> and also serves as a Resource Directory Description
> for the namespace http://www.rddl.org/.
> -- http://www.openhealth.org/RDDL/20010122/rddl-20010122.html
> That says "*the* syntax and semantics"; which, when taken
> literally, suggests that there shall never be another syntax/semantics
> associated with this namespace. Is that what you meant to say?
> Or do you reserve the right to revise the syntax and
> semantics associated with that namespace name? If so
> (and I suspect this is the case), please document the
> persitence/change policy for that namespace; for example
> policies, please see:
right, this needs doing.
> URIs for W3C namespaces
> Thu, 21 Dec 2000 18:41:28 GMT
> especially the section
> Template policy
> A simple policy like
> subject to change without notice
> suffices, though I suspect something more like
> The specification of this namespace is subject
> to change; in the case of substantive change,
> the editors intend to notify the
> users of this technology via the xml-dev forum at least
> one week in advance.
> is what you want. You might add news:comp.text.xml
> as a change notice forum for redundancy.
> If you're aware of any sort of changes to the spec that
> would motivate you to choose a new namespace name,
> (e.g. backwards-incompatible changes, etc.)
> please point those out too.
how do xml-dev'ers suggest we handle namespace versioning? i'm not totally
wed to http://www.rddl.org/ (except that I shelled out $11 for a gandi.net
DNS name and the spec/code is riddled with this URI (sorry :-))
The only thing in the spec that directly refers to this URI is as follows:
1) The default resource nature is "http://www.rddl.org/#resource"
2) http://www.rddl.org/natures and http://www.rddl.org/purposes refer to
RDDL documents describing 'well known' natures and purposes (and to
reiterate people are free to create their own nature and purpose URIs)
This dependency itself could be removed except for the curious requirement
that the URI part of a URI reference be absolute in xlink:arcrole and
xlink:role -- curious because this leaves open the option of a bare fragment
identifier which is essentially a relative URI reference. I expect that the
intention is to require these to be an absolute URI with optional fragment
I *should* provide <rddl:resource ..><p>This version ...</p></rddl:resource>
and ditto: Lastest version, previous version entries where the <a> refs are
> [Feel free to forward this message to xml-dev; I still
> haven't figured out how to subscribe to it without my
> inbox becoming unmanageable. Sorry. I do try
> to read the archives now and again, especially
> when xmlhack.com etc. highlights something. If the maintainers
> have some way of giving me posting privileges without
> delivering all the mail to me, that would make
> my life easier.]
Thanks for the feedback -- and reference to prior art -- there almost always
is some :-)
> Dan Connolly, W3C http://www.w3.org/People/Connolly/