Re: [core] Link target attributes in CoRAL (was: Review of CoRAL)

[Klaus Hartke <[e-mail]>]

Christian Amsüss wrote:
> Non-target link attributes are something I'd discourage in general;
> would you, when someone does define new non-target attributes, encourage
> them to specify how they'd be expressed in CoRAL?

I think I don't care enough about Link Format that I'd encourage
maintaining any kind of mapping. The draft currently describes a
generic mapping that works for any target attribute but makes no
attempt to work for any non-target attribute. If I could get rid of
the mapping, I would do it.

> > Since in CoRAL it's possible to make statements about link targets
> > (here: the literal "Überschrift"), something like this would look
> > natural to me:
> >
> >       #using iana = <http://www.iana.org/assignments/relation/>
> >       #using attr = <http://TBD2/>
> >
> >       iana:terms-of-service </tos> {
> >          attr:title "Nutzungsbedingungen" { attr:hreflang "de" }
> >          attr:title "Terms of use"        { attr:hreflang "en" }
> >       }
> >
> >    <=>
> >
> >       </tos>; rel=terms-of-service;
> >          title*=UTF-8'de'Nutzungsbedingungen;
> >          title*=UTF-8'en'Terms%20of%20use
>
> That's kind of neat and kind of scary.

Good point. I'm open to other ideas. But I think I don't want make
processing much more complex to accommodate language-tagged strings,
since it's unlikely that a constrained device will serve links
annotated with titles in 20 languages.

> > If there's a guarantee that there won't be any new link target
> > attributes in the future (for RFC 6690 link serializations), then we
> > could skip the whole mapping topic and just define a new, more natural
> > set of link relation types:
>
> I don't think we need a guarantee for that. We can, as they pop up, for
> some funny-string-valued attributes define equivalent more semantic
> attributes, each with their own mapping. So a general CoRAL processor
> you could encounter both `attr: rt="x y"` or `split-attr:rt rt:x,
> split-attr rt:y` and needs to know of the equivalence.

This is exactly what I'd like to avoid.

IMO we should decide on either a generic mapping that can round-trip
any attributes or a new set of relations, but not both:
Implementations could never rely on that the other kind doesn't appear
and therefore would have to support both, which doesn't help with
keeping developers happy and implementation sizes small.

Klaus