Re: [xri] <Title>

[Eran Hammer-Lahav <eran@hueniverse.com>]

You are missing the point. The question is if there is value in a  
simple and generic way to add human readable line to a link, the same  
way provided by the other link constructs. If you need more, that's  
when you go use something else. My question is if there is enough need  
for a generic element which is available elsewhere.

EHL

On Sep 11, 2009, at 22:42, "Joseph Anthony Pasquale Holsten" <joseph.holsten@cordance.net 
 > wrote:

> 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.
> --
> http://josephholsten.com