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


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [xri] <Title>

EHL wrote:
> All the other link structures (header, element) provide a link-level  
> title with language support. Should we add something like that to  
> stay consistent? This is extremely useful in building UI for editing  
> and presenting XRD documents to users, especially in the social  
> space which is an important target for us. This came up in pretty  
> much every place XRDS-Simple was discussed.


> It will look something like this:


>   <Title lang='en-us'>A very special link</Title>


> Cardinality is 0 to any. 'lang' is optional and does not have a  
> default value is omitted. It will use a standard languages code spec  
> (whatever is the prevailing reference today).

Will wrote:
> since this discussion is generally about management of XRDs, it's  
> worth noting that Joseph asked me some months ago about adding an  
> xml:id to <Link>.  This is actually more useful when there is some  
> API that would allow a service to modify entries in an XRD document,  
> needing to refer to a specific Link by ID.  While that kind of API  
> is still some ways off, and a <Title> element actually has  
> application in the nearer term, I think it begs the question of how  
> much management related elements would should be adding to the core  
> spec.  While having the title embedded in the document directly is  
> certainly convenient, it is by no means necessary (implementations  
> could store it elsewhere).  Nor does it aid in any way the primary  
> goal of XRD -- to create a *machine-readable* format for describing  
> resources.

I think this stuff shouldn't be invented by XRD. It's a slippery slope  
into work that's already available through other systems.

Should we allow embedding markup inside the element? Should it specify  
a type, as with text constructs in Atom? Should we allow HTML? Just  
the XML encodings of XHTML, HTML5? What about non-XML HTML 4 or HTML  
5? Single encoded? People will inevitably try to stick HTML in it  
anyway regardless.

Should we define the presentation semantics of this? Half the link  
structures (html anchors, xlink in SVG) use the title information for  
tooltips. Others use the title as the visual representation of the  
link. Which is right?

How about the useful stuff in OpenSearch? Include a short name, a long  
name, and a description. Favicons, or just images of various sizes.   
Maybe tags. And contact info. Copyright data. Content-encoding.  
Complex URI-templates. Parameter validation. Heck let's just throw in  
all of RDF and WADL and WSDL and IDL.

Or, you know. Not.

XRD is perfect for collecting the formal link semantics from things  
like HTML, Atom, Link Headers and so on. But unlike it's predecessors,  
it should not try to solve any presentational goal. If you want a  
title, how about not using XRD at all. HTML is more than capable of  
expressing the link semantics that some believe should be so entitled.  
You won't even need a microformat, because they're just links. If you  
really need it, embed the XRD into some presentational format.

Am I ignoring the fact that presentational formats have crap  
capabilities for security and trust and PKI? Yes. But you're already  
embedding external semantics from dSig, so those situations can also  
embed external semantics from Dublin Core or XLink or RDF.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]