Draft 4 Proposal: "rel" attribute for <Url>
10 views
Skip to first unread message
BrandonLive
Oct 8, 2008, 3:13:32 PM10/8/08
to OpenSearch
As per the other thread, it sounds like creating individual threads is
the way to go in order to discuss and document changes for Draft 4.
The addition to the <Url> Element section would consist of:
Attributes:
::existing attributes::
rel - Defines the relationship between the OSD file and the Url
described in this element.
Default: "results".
Requirements: This attribute is optional but recommended. If a rel
value other than "results" is specified for a given format, it should
appear after the "results" <Url> element for compatibility with
existing clients.
This attribute removes the need to hack "suggestions" and other things
into the "format" attribute, and would allow search suggestions to be
provided in a variety of formats (ie <Url format="application/rss+xml"
rel="suggestions" template="foobar"/>)
Other possible "rel" values to document would be:
"preview" - a preview of the search results in a low-resolution format
(see the thread on IE8's usage).
"itemlist" - a complete list of all items within the scope of this
search location
"recent" - a list of items recently added to this scope
And I could probably think of more =)
the way to go in order to discuss and document changes for Draft 4.
The addition to the <Url> Element section would consist of:
Attributes:
::existing attributes::
rel - Defines the relationship between the OSD file and the Url
described in this element.
Default: "results".
Requirements: This attribute is optional but recommended. If a rel
value other than "results" is specified for a given format, it should
appear after the "results" <Url> element for compatibility with
existing clients.
This attribute removes the need to hack "suggestions" and other things
into the "format" attribute, and would allow search suggestions to be
provided in a variety of formats (ie <Url format="application/rss+xml"
rel="suggestions" template="foobar"/>)
Other possible "rel" values to document would be:
"preview" - a preview of the search results in a low-resolution format
(see the thread on IE8's usage).
"itemlist" - a complete list of all items within the scope of this
search location
"recent" - a list of items recently added to this scope
And I could probably think of more =)
DeWitt Clinton
Oct 8, 2008, 3:53:55 PM10/8/08
to opens...@googlegroups.com
Responses inline...
On Wed, Oct 8, 2008 at 12:13 PM, BrandonLive <bra...@brandonlive.com> wrote:
As per the other thread, it sounds like creating individual threads is
the way to go in order to discuss and document changes for Draft 4.
Thanks!
The addition to the <Url> Element section would consist of:
Attributes:
::existing attributes::
rel - Defines the relationship between the OSD file and the Url
described in this element.
+1 I'm generally in favor of this, insofar as the 'rel' attribute feels like the right way to express what we want. But there are a few caveats I'll get to below.
Default: "results".
+1 It is subjective of course, but "results" feels like the right word for it to me.
Requirements: This attribute is optional but recommended.
-1 No need to make it recommended. The default matches the user's expectations. Instead, how about:
Requirements: This attribute is optional.
If a rel
value other than "results" is specified for a given format, it should
appear after the "results" <Url> element for compatibility with
existing clients.
-1 I'd rather we didn't specify ordering here. I know that some clients today only look at the first Url, but hinting that non-"results" Urls should appear later in XML-ordering doesn't avoid the need for the clients to use heuristics to pick among different search types.
This attribute removes the need to hack "suggestions" and other things
into the "format" attribute, and would allow search suggestions to be
provided in a variety of formats (ie <Url format="application/rss+xml"
rel="suggestions" template="foobar"/>)
-1 The 'type' attribute expresses this already in a way that is consistent with similar elements in HTML and Atom. How is 'format' better?
Other possible "rel" values to document would be:
And here's the meat of my reservation. I don't want to add complexity just because of neat ideas. If we can document the rel values clearly and show some live examples in the real world (like we have with "results" and "suggestions") then lets go for it, otherwise let's pass on adding them now. (I made a mistake by allowing too many speculative values that no one uses for the 'role' attribute on the Query.element.)
"preview" - a preview of the search results in a low-resolution format
(see the thread on IE8's usage).
Can you take a stab at documenting this?
Thanks for the spec proposal, Brandon! This is exactly what I think we need to make progress.
-DeWitt
BrandonLive
Oct 8, 2008, 4:36:10 PM10/8/08
to OpenSearch
Thanks Dewitt.
Some inline responses:
> > Requirements: This attribute is optional but recommended.
>
> -1 No need to make it recommended. The default matches the user's
> expectations. Instead, how about:
That's fine with me.
> -1 I'd rather we didn't specify ordering here. I know that some clients
> today only look at the first Url, but hinting that non-"results" Urls should
> appear later in XML-ordering doesn't avoid the need for the clients to use
> heuristics to pick among different search types.
I'm also fine with that, but my concern would be for a new implementer
who wants to target IE8 and puts a "preview" URL ahead of their
"results" URL will undoubtedly hit unexpected behavior with clients
like IE7, who will try to use the "preview" URL for the search query.
> -1 The 'type' attribute expresses this already in a way that is consistent
> with similar elements in HTML and Atom. How is 'format' better?
Sorry, when I said "format" I meant "type" - I think we agree here. I
was just explaining that something like the existing "application/x-
suggestions+json" type is wrong, and that it should have the normal
JSON mime identifier as its "type" and use "rel" to define it usage.
The current "application/x-suggestions+json" type value in the
Suggestions spec uses the "type" attribute to define both the format
and the intended usage, whereas I think we both agree these should be
seperate.
>
> Other possible "rel" values to document would be:
>
>
>
> And here's the meat of my reservation. I don't want to add complexity just
> because of neat ideas. If we can document the rel values clearly and show
> some live examples in the real world (like we have with "results" and
> "suggestions") then lets go for it, otherwise let's pass on adding them
> now. (I made a mistake by allowing too many speculative values that no one
> uses for the 'role' attribute on the Query.element.)
Agreed. But... I have a project where the "itemlist" example has
already been implemented :)
I would love to have this be a part of the common spec instead of a
custom extension as I think it is generally useful to other consumers.
Some inline responses:
> > Requirements: This attribute is optional but recommended.
>
> -1 No need to make it recommended. The default matches the user's
> expectations. Instead, how about:
> -1 I'd rather we didn't specify ordering here. I know that some clients
> today only look at the first Url, but hinting that non-"results" Urls should
> appear later in XML-ordering doesn't avoid the need for the clients to use
> heuristics to pick among different search types.
who wants to target IE8 and puts a "preview" URL ahead of their
"results" URL will undoubtedly hit unexpected behavior with clients
like IE7, who will try to use the "preview" URL for the search query.
> -1 The 'type' attribute expresses this already in a way that is consistent
> with similar elements in HTML and Atom. How is 'format' better?
was just explaining that something like the existing "application/x-
suggestions+json" type is wrong, and that it should have the normal
JSON mime identifier as its "type" and use "rel" to define it usage.
The current "application/x-suggestions+json" type value in the
Suggestions spec uses the "type" attribute to define both the format
and the intended usage, whereas I think we both agree these should be
seperate.
>
> Other possible "rel" values to document would be:
>
>
>
> And here's the meat of my reservation. I don't want to add complexity just
> because of neat ideas. If we can document the rel values clearly and show
> some live examples in the real world (like we have with "results" and
> "suggestions") then lets go for it, otherwise let's pass on adding them
> now. (I made a mistake by allowing too many speculative values that no one
> uses for the 'role' attribute on the Query.element.)
already been implemented :)
I would love to have this be a part of the common spec instead of a
custom extension as I think it is generally useful to other consumers.
DeWitt Clinton
Oct 8, 2008, 4:54:40 PM10/8/08
to opens...@googlegroups.com
See inline.
On Wed, Oct 8, 2008 at 1:36 PM, BrandonLive <bra...@brandonlive.com> wrote:
> -1 I'd rather we didn't specify ordering here. I know that some clientsI'm also fine with that, but my concern would be for a new implementer
> today only look at the first Url, but hinting that non-"results" Urls should
> appear later in XML-ordering doesn't avoid the need for the clients to use
> heuristics to pick among different search types.
who wants to target IE8 and puts a "preview" URL ahead of their
"results" URL will undoubtedly hit unexpected behavior with clients
like IE7, who will try to use the "preview" URL for the search query.
Description document owners will figure it out quickly, I suspect. And we could add a warning to the validator.
> -1 The 'type' attribute expresses this already in a way that is consistentSorry, when I said "format" I meant "type" - I think we agree here. I
> with similar elements in HTML and Atom. How is 'format' better?
was just explaining that something like the existing "application/x-
suggestions+json" type is wrong, and that it should have the normal
JSON mime identifier as its "type" and use "rel" to define it usage.
The current "application/x-suggestions+json" type value in the
Suggestions spec uses the "type" attribute to define both the format
and the intended usage, whereas I think we both agree these should be
seperate.
Ahh, now I understand. Yes, that makes great sense to me.
So these are equivalent:
<Url rel="suggestions" type="application/json" template="http://example.com/suggest?q={searchTerms} />
<Url type="application/x-suggestions+json" template="http://example.com/suggest?q={searchTerms} />
While the latter would now be discouraged, many clients will no doubt want to support it still. Given that the only place the "application/x-suggestions+json" appears is the Suggestions 1.0 spec (which, incidentally, I just branched to create 1.1), it sounds like we can confine our commentary about backward compatibility there.
If I understand correctly, then objection withdrawn. +1
Agreed. But... I have a project where the "itemlist" example has
> And here's the meat of my reservation. I don't want to add complexity just
> because of neat ideas. If we can document the rel values clearly and show
> some live examples in the real world (like we have with "results" and
> "suggestions") then lets go for it, otherwise let's pass on adding them
> now. (I made a mistake by allowing too many speculative values that no one
> uses for the 'role' attribute on the Query.element.)
already been implemented :)
Is this something you can share with the group?
Thanks!
-DeWitt
BrandonLive
Oct 8, 2008, 5:22:55 PM10/8/08
to OpenSearch
Responses inline.
> Description document owners will figure it out quickly, I suspect. And we
> could add a warning to the validator.
Yeah, that makes sense to me.
> Ahh, now I understand. Yes, that makes great sense to me.
>
> So these are equivalent:
>
> <Url rel="suggestions" type="application/json" template="http://example.com/suggest?q={searchTerms} />
> <Url type="application/x-suggestions+json" template="http://example.com/suggest?q={searchTerms} />
Precisely.
> While the latter would now be discouraged, many clients will no doubt want
> to support it still. Given that the only place the
> "application/x-suggestions+json" appears is the Suggestions 1.0 spec (which,
> incidentally, I just branched to create 1.1), it sounds like we can confine
> our commentary about backward compatibility there.
Sounds good :)
> > Agreed. But... I have a project where the "itemlist" example has
> > already been implemented :)
>
> Is this something you can share with the group?
Unfortunately, nothing ready to share quite yet. Should have
something to show pretty soon though, and I think you'll like it.
> Description document owners will figure it out quickly, I suspect. And we
> could add a warning to the validator.
> Ahh, now I understand. Yes, that makes great sense to me.
>
> So these are equivalent:
>
> <Url rel="suggestions" type="application/json" template="http://example.com/suggest?q={searchTerms} />
> <Url type="application/x-suggestions+json" template="http://example.com/suggest?q={searchTerms} />
> While the latter would now be discouraged, many clients will no doubt want
> to support it still. Given that the only place the
> "application/x-suggestions+json" appears is the Suggestions 1.0 spec (which,
> incidentally, I just branched to create 1.1), it sounds like we can confine
> our commentary about backward compatibility there.
> > Agreed. But... I have a project where the "itemlist" example has
> > already been implemented :)
>
> Is this something you can share with the group?
something to show pretty soon though, and I think you'll like it.
DeWitt Clinton
Oct 8, 2008, 11:05:54 PM10/8/08
to opens...@googlegroups.com
One last question on this:
What's the incentive for an author to use the new rel="suggestions" type="application/json" syntax?
All the existing clients -- say some 70% of the market share -- support only the old syntax Future browsers may support rel="suggestions", but even those new browsers will support the old syntax, so why would anyone switch? Even many years from now there will still be a huge percentage of clients that only support the old format, thus publishers have an incentive not to adopt the newer format.
Following that logic, I imagine that we'll see a lot of hybrid Urls with the new "rel" attribute and the old mime-type:
<Url rel="suggestions" type="application/x-suggestions+json" template="http://example.com/suggest?q={searchTerms} />
Which would presumably work with both old and new clients alike. We should test this.
-DeWitt
What's the incentive for an author to use the new rel="suggestions" type="application/json" syntax?
All the existing clients -- say some 70% of the market share -- support only the old syntax Future browsers may support rel="suggestions", but even those new browsers will support the old syntax, so why would anyone switch? Even many years from now there will still be a huge percentage of clients that only support the old format, thus publishers have an incentive not to adopt the newer format.
Following that logic, I imagine that we'll see a lot of hybrid Urls with the new "rel" attribute and the old mime-type:
<Url rel="suggestions" type="application/x-suggestions+json" template="http://example.com/suggest?q={searchTerms} />
Which would presumably work with both old and new clients alike. We should test this.
-DeWitt
steve
Nov 27, 2008, 12:29:24 PM11/27/08
to OpenSearch
Sorry... I realize this thread is a bit old but...
The incentive to support rel="suggestions" is that clients can now
return suggestions in a format other then JSON. Win7 for instance
doesn't have a JSON parser and I'm sure Brandon doesn't want to have
to implement one if he doesn't have to. Separating the the templates
relationship from its return type means servers can return suggestions
as "application/atom+xml" if the want them to show up in Windows (or
other clients without JSON parsers.)
I don't think Win7 currently supports suggestions so this isn't a huge
deal but I think the argument is valid.
-steve
The incentive to support rel="suggestions" is that clients can now
return suggestions in a format other then JSON. Win7 for instance
doesn't have a JSON parser and I'm sure Brandon doesn't want to have
to implement one if he doesn't have to. Separating the the templates
relationship from its return type means servers can return suggestions
as "application/atom+xml" if the want them to show up in Windows (or
other clients without JSON parsers.)
I don't think Win7 currently supports suggestions so this isn't a huge
deal but I think the argument is valid.
-steve
DeWitt Clinton
Nov 27, 2008, 12:57:04 PM11/27/08
to opens...@googlegroups.com
Oh, I totally agree. The principle behind rel="suggestions" is sound and I think there is wide consensus on that.
My point was simply that, because most existing clients aren't aware of it, how are we going to encourage adoption in new description documents?
But in any case I feel we should proceed with the rel recommendation. Does anyone want to write that up as a community proposal on the wiki? Maybe at http://www.opensearch.org/Community/Proposal/Url_Rel_Attribute?
-DeWitt
My point was simply that, because most existing clients aren't aware of it, how are we going to encourage adoption in new description documents?
But in any case I feel we should proceed with the rel recommendation. Does anyone want to write that up as a community proposal on the wiki? Maybe at http://www.opensearch.org/Community/Proposal/Url_Rel_Attribute?
-DeWitt
Gavin Sharp
Nov 27, 2008, 2:12:37 PM11/27/08
to opens...@googlegroups.com
On Thu, Nov 27, 2008 at 12:57 PM, DeWitt Clinton <dew...@unto.net> wrote:
> My point was simply that, because most existing clients aren't aware of it,
> how are we going to encourage adoption in new description documents?
> My point was simply that, because most existing clients aren't aware of it,
> how are we going to encourage adoption in new description documents?
It would be fairly simple to implement in Firefox (our search service
is implemented in JavaScript), and could likely land for Firefox 3.1.
If anyone's interested in doing the work I can provide guidance and
help get it landed - a good first step would be to file a bug about it
at https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox&component=Search
and CC me.
Gavin
Reply all
Reply to author
Forward
0 new messages