RE: Minimal RDDL [NamespaceDocument-8]

I love it. I only have 3 questions 

1.) Who has the authority to create new natures and purposes? 
2.) Using namespace URIs  for nature/purpose probably doesn't cut it.
The W3C XML Schema working group may not rev the namespace for
subsequent versions of the REC and the XSLT working group is definitely
not going to. So should RDDL nature/purpose contain versioning
information or should that be embedded in the targets of the href? 
3.) Is there a mechanism for dealing with multiple href targets that
have the same nature and purpose besides UAs just picking the first one?
The first that comes to mind is having multiple stylesheets for the same
XML document. One could say that you should have different purposes for
each stylesheet which then takes us back to question (1). 

Besides the above questions I believe this is the sanest RDDL proposal
yet. It is simple to author and unintrusive yet meets the requirements
as a mechansim for locating machine processable metadata about an XML
namespace. 

-- 
PITHY WORDS OF WISDOM 
Identical units which test in an identical fashion will not behave in an
identical fashion in the field.                               

This posting is provided "AS IS" with no warranties, and confers no
rights. 

>  
>  
> -----Original Message-----
> From: Tim Bray [mailto:tbray@textuality.com] 
> Sent: Friday, February 14, 2003 2:34 PM
> To: WWW-Tag
> 
> 
> I have an action item, working with Paul Cotton, to produce a 
> draft of RDDL based on the discussion we've had around the 
> TAG.  I reviewed the input, talked to Paul, and co-author 
> Jonathan Borden, and got to
> 
>   http://www.textuality.com/xml/rddl3.html
> 
> Here's how.  The original RDDL draft from Borden and me was 
> XHTML plus a new element <rddl:resource> with a bunch of 
> ordinary attributes like title and description, plus two 
> special ones "nature" (namespace name or mime type) and 
> "purpose" (what you want to use this for).  Both nature and 
> purpose were going to be URIs; RDDL was going to provide a 
> bunch of useful pre-cooked purposes.
> 
> People coming from the Semantic Web direction (including 
> co-author Jonathan Borden) argued in favor of several 
> different RDF representations, but they all had significant 
> overhead, and furthermore IMHO failed to achieve their 
> semantic-web objective while simultaneously making RDDL 
> uglier less useful in terms of its original goal.  I just 
> don't think the community will buy into any of those alternatives.
> 
> Next, Sandro Hawke suggested just using the existing 
> <xhtml:a> element, which has little-used attributes rel= and 
> type= which fit pretty well perfectly onto "nature" and 
> "purpose".  See 
> http://lists.w3.org/Archives/Public/www-tag/2002Dec/0232.html.
>   Turns out there are two problems with this.  First of all, 
> how do you know that some particular <html:a> is pointing to 
> related-resources, rather than just being a human-oriented 
> hyperlink right there in the text? 
> Second, it turns out that rel= and type= come preloaded with 
> a bunch of fuzzy semantics,  I've appended a private email 
> from Sandro.  Having read it, it seemed likely impossible to 
> cleanly reuse rel= and type=.
> 
> So, in conclusion, the above is a RDDL proposal using 
> <html:a> elements,
>   not trying to re-use the "rel" and "rev" attributes, but 
> rather introducing just two new attributes, rddl:nature and 
> rddl:purpose.  The <html:a> element has tons of other useful 
> attributes like "title" and "longdesc" and so on already, 
> people can use those if they want to and occasionally 
> browsers will even do something useful with them.
> 
> Bear in mind that *all* these RDDL proposals are more or less 
> isomorphic in that you could turn pretty well any of them 
> into pretty well any of the others with an XSLT script.  -Tim
> 
> Sandro's note ==============================================
> 
>  >> 1. The TAG seems to have consensus that we should move 
> forward toward  >> something to fill the RDDL hole, and I 
> have part of the job of producing  >> a first-cut WD.  I 
> would like to base it on your suggestion using the  >> 
> existing attributes of <html:a (described at  >> 
> http://lists.w3.org/Archives/Public/www-tag/2002Dec/0232.html)
> , just  >> because it seems like the simplest possible way to 
> proceed.  Someone  >> piped up and said that your proposal 
> was invalid per some HTML rule or  >> another but I never 
> took the trouble to figure out whether this was  >> right or 
> not.  Is there a problem and does your proposal need  >> 
> modification to work around this?
> 
> I discussed the problem in a followup [1] and then offered an 
> amended proposal [2] which should be valid in all HTMLs.  
> It's a vaguely unpleasant situation with XHTML 1.1.  The 
> document linked in [2] contains the amended rddl challenge 
> text, or see [3].  One could also do the imports using LINK 
> in the HEAD, I suppose, if one wanted them to be invisible.
> 
>  >> Also, another question... does the profile= attribute in 
> the <html:head  >> element mean that for all <html:a 
> attributes, the rel= and type= have  >> the RDDL semantics?  
> Or is there a case to be made for some other  >> syntactic 
> mechanism to distinguish <html:a's which are RDDL pointers as 
>  >> opposed to generic links?
> 
> I think profiles allow you to define additional link types 
> (values for rel=), but not change existing ones [4].  I'm 
> thinking these RDDL semantics for type are the same as the 
> existing semantics (a hint as to what Content-Type you'll get 
> if you do a GET), so there's no issue
> there.   This kind of relies on the TAG view that Content-Type values
> should be viewed as URIs.
> 
> It's hard to find an example of profile= which doesn't have Dan
> Connolly's name on it.   :-)
> 
> [1] http://lists.w3.org/Archives/Public/www-tag/2002Dec/0234.html
> [2] http://lists.w3.org/Archives/Public/www-tag/2002Dec/0236.html
> [3] http://www.w3.org/2002/12/ns/rddl-challenge.html
> [4] http://www.w3.org/TR/html401/types.html#type-links
> 
> ==============================================================
> ===========
> 
>

Received on Friday, 14 February 2003 18:00:07 UTC