[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xri] <Title>
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]