* Eric Scheid <[EMAIL PROTECTED]> [2005-07-13 17:35]: > could we have @href and then also @idref ... then when we mean > to provide a dereferenceable uri we can put it in @href, and > when we want to provide an ID reference we can put it in > @idref. We can even put both into a link, and if the @href > returns a 404 or otherwise indicate it is not the thing being > sought, then we could try querying an ID resolver to find the > new location.
It would make more sense to me to say that a particular type of @rel value always expects a dereferencable URI or never expects on. “in-reply-to” would be in the latter category. I can see the value in having both for cases where the relationship may easily be either case. Although I don’t like the idea of both attributes being present at once; a Link Construct should refer to one resource, IMHO, and building some kind of fallback mechanism into it rubs me the wrong way for reasons I can’t quite verbalize yet. In which case you could add another attribute to cover this. Or you could decompose it into two relationship types, both of which mean the exact same, but of which one expects a dereferncable URI and the other expects an abstract one. So as far as I can tell, if we say that @href may contain any URI, and the semantics of that URI are defined by the value of @rel, this allows any scenario which @idref would, except for providing that fallback mechanism. So, I don’t know… I can see merit in @idref, though I lean against it. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
