Internet Explorer 8 and OpenSearch extensions

[Niall Kennedy]

Yesterday Microsoft released to the web its second beta of Internet
Explorer 8 [1] web browser. The final release of Internet Explorer 8
is expected before the end of the year and includes new "Instant
Search" functionality [2] built on top of, and extending, the
OpenSearch specification.

Microsoft has made some choices in the early versions of its
developer documentation that seem counter to the existing OpenSearch
spec and could introduce developer confusion. We may have an
opportunity to quickly work with the Internet Explorer team to clean
up both the OpenSearch 1.1 spec, and Microsoft's extensions utilized
in IE8, before IE8 hits full release to Web status.

The OpenSearch spec states:
"OpenSearch description documents can be extended with foreign markup
provided that all foreign elements and attributes are associated with
an explicit XML namespace distinct from that of the core OpenSearch
format"
http://www.opensearch.org/Specifications/OpenSearch/1.1#Extensibility

The core OpenSearch format is defined by 1.1 with namespace
extensions available to agents extending core. Microsoft's current
implementation does not seem to embrace this extensibility and instead
introduces new parameters into the core description.

Example: OpenSearch 1.1 defines an exhaustive list of local
parameter names that may appear unqualified in a URL template [3].
Microsoft has included its own set of unqualified parameter names not
included in core.

maxWidth - the width of a drop-down box, in pixels
sectionHeight - the height of the entire suggestions drop-down
rowHeight - the height of a single line of text
From: http://msdn.microsoft.com/en-us/library/cc848862.aspx#dev_dimensions

Microsoft has also added qualified namespaces such as "referrer" in
its developer documentation without declaring a specific XML
namespace.

I suggest Microsoft move these new parameter names into a new
namespace or namespaces to maintain compliance and validation with
OpenSearch 1.1 core. I also suggest a complete rework of the
OpenSearch Suggestions extension [4] to incorporate new
implementations from Microsoft and others.

I would like to form a working group within the OpenSearch community
to work with Microsoft, and other interested implementers able to
execute quickly, to align OpenSearch 1.1 spec and the IE8
implementation. If we can harden out best practices and interoperable
formats we will strengthen OpenSearch and the role it can play across
multiple agents.

There are a lot more OpenSearch issues in IE8 I haven't even raised
in this e-mail. Keeping things simple with just parameter names for
now.


-Niall Kennedy


[1] http://www.microsoft.com/ie8
[2] http://www.microsoft.com/windows/internet-explorer/beta/features/instant-search.aspx
[3] http://www.opensearch.org/Specifications/OpenSearch/1.1#OpenSearch_1.1_parameters
[4] http://www.opensearch.org/Specifications/OpenSearch/Extensions/Suggestions/1.0

[DeWitt Clinton]

Thanks for kicking this off, Niall!  I agree that this list is a good place to have that discussion.

More, of course, to follow...

-DeWitt

[Niall Kennedy]

I have submitted the parameter names issue to the official Internet
Explorer 8 beta feedback channel for further clarification. If you
have a Windows Live ID you can vote up the issue as "Helpful" to raise
its profile.

http://www.microsoft.com/communities/newsgroups/list/en-us/default.aspx?dg=microsoft.public.internetexplorer.beta&tid=2b9091e0-8bc8-43e1-827d-ddef43aee953&cat=en_us_2BAF8EC5-645C-4477-A380-0F1CF6C102F9

-Niall Kennedy

> >http://www.microsoft.com/windows/internet-explorer/beta/features/inst...
> > [3]
> >http://www.opensearch.org/Specifications/OpenSearch/1.1#OpenSearch_1....
> > [4]
> >http://www.opensearch.org/Specifications/OpenSearch/Extensions/Sugges...

[Frank Ellermann]

Niall Kennedy wrote:

> If you have a Windows Live ID you can vote up the issue
> as "Helpful" to raise its profile.

Done, surprisingly I recalled my password. This will not
help, anything IE8 is *far* too late to change now, last
minute IE8 fixes are unlikely for irrelevant details like
OpenSearch.

Clearly the lack of a stable published specification with
a registered link relation and a registered MIME subtype
should have top priority. As log as that does not exist
everybody and his dog (or browser) will invent features
as they see fit, still claiming that this is "OpenSearch".

The specification should have absolute priority. We are
apparently clear to try the IETF APPS approach, because
we anyway need those "standards tree" IANA registrations.

And maybe we're clear to add <SearchForm>, after all it's
not too bad, unlike other elements it even has an effect
in millions of browsers.

As long as OpenSearch appears to be a moving target any
developer, MS or otherwise, is tempted to contribute to
this movement. We need that RFC.

Just in case, the only reason I'm here is because I think
it is *excessively* *annoying* behaviour to squat a name
for a MIME type in the standards tree without standard.

To be perfectly clear, "name squatting" is the tactics of
spammers. MIME has a vendor tree, and a vanity tree, for
vnd.microsoft.icon (favicon), vnd.google.earth or similar
for KML. But OpenSearch claims to be "standard" and more
important than favicon + Google Earth.

Prove it, finally.

Frank

[Sharon]

Hi Niall, DeWitt and others –

Thanks very much for the initial feedback on our OpenSearch
extensions. We are very happy to have shipped and be able to have
this feedback loop. It was not our intention to create any
discrepencies with the OpenSearch 1.1 spec.

We have had some initial conversations with DeWitt and we are excited
to be able to discuss this openly and collect all your feedback. We
are open to making changes based on your comments but obviously we
can’t commit to anything specific until evaluating the feedback.

Thanks very much. We are looking forward to the discussion.

-sharon [msft]

[Derek Gottfrid]

as a long timer lurker on the list and one of the initial implements.
i am most interested in this discussion.
adding the namespacing seems a no brainer. i would actually like to
see a json formated spec
as well.

d

[Sharon]

Hey Niall –

In regards to your initial feedback. We are still in the process of
evaluating the usefulness of the additional suggestion url parameters
with our partners, however, we will also take a note that these should
be in a namespace.

I believe your comment on the referrer namespace is regarding this
code example (toward the bottom of the article):

<Url type="application/x-suggestions+xml"
template="http://search.mysite.com/suggestions/
results.aspx?
q={searchTerms}&amp;src={referrer:source?}&amp;

maxwidth={maxWidth}&amp;rowheight={rowHeight}&amp;sectionHeight={sectionHeight}" /
>


In this example, the referrer:source really isn’t crucial so we can
just remove it (but this was never intended to be a full OSD file
example… (If there’s something else in the documentation that I
missed about this comment please let me know.)

Also a question for everyone. What are your thoughts on the best way
to add a PreviewUrl to an OSD file?

The method we are using for beta 2 is:
<?xml version="1.0" encoding="UTF-8"?>
<OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/"
xmlns:ie = “http://schemas.microsoft.com/search/2008/”>
…
<ie:PreviewUrl>http://example.com/preview/q={searchTerms}</
ie:PreviewURL>
</OpenSearchDescription>

Do you think this method is good or would you prefer to see this in an
<Url> element?

-sharon

[Frank Ellermann]

Sharon wrote:

> Also a question for everyone. What are your thoughts on
> the best way to add a PreviewUrl to an OSD file?

> The method we are using for beta 2 is:

[...]

> xmlns:ie = “http://schemas.microsoft.com/search/2008/”

Yes, I think that's the idea to pull in additional features
in their own namespaces. If you want to go that way IMHO
two things are important:

(1) For human readers the namespace identifier should be a
real URL, not a 404, going to a specification of the
namespace.
(2) The namespace should get an entry on the opensearch.org
pages, for existing examples see
http://www.opensearch.org/Specifications/OpenSearch/Extensions

It would be a pain for you to maintain two copies of your
specification, to avoid this you could give a short intro
with a link to your "own" (MSDN) site for the fine print.

Or vice versa, but I guess MSDN users won't be thrilled by
a link to an external (from their POV) OpenSearch.org page.

> <ie:PreviewUrl>http://example.com/preview/q={searchTerms}
> </ie:PreviewURL>

[...]

> Do you think this method is good

I've not the faintest idea what a "preview URL" for a search
query is, so I guess I wouldn't add this to my descriptions.

But otherwise it is clear. I'm not sure about using <Url>,
if more than one <Url> exists their difference is indicated
by the (result) type attribute, e.g., type="text/html".

There is no type="text/preview+xml" or similar, therefore I
think you can't use the existing <Url> element directly.

If a "preview" is an image (thumbnail) I missed your point,
<Url type="image/png" ... /> could be perfect.

Frank

[Niall Kennedy]

Yes, my reference was to the referrer namespace inside the
dev_dimensions example. Best to remove that mention as it is not
introduced as a concept until the next section in the document and no
namespace declaration is present to define referrer.

How does PreviewUrl differ from a Url element with a type attribute of
text/html, application/xhtml+xml, or text/plain? What Accept headers
are you sending with your request for an Accelerator preview, and how
might that affect your accepted render? Could there be a benefit to
Internet Explorer 8 taking advantage of existing descriptor documents
with an acceptable response template? If it is merely a question of
size of the rendered result, would adding the additional dimension
parameters help solve the issue?

-Niall Kennedy

> > >http://www.microsoft.com/communities/newsgroups/list/en-us/default.as...

[Sharon]

Sorry for not being a little clearer in my initial post.

Accelerators are a new IE8 feature which let you select text on a page
and send it to any other service. (mapping, blog, translate, etc.)
As part of this new feature, Accelerators are able to display a
"preview" window of the service which is just a small section of
html. You can see some pictures and more details over here:
http://www.microsoft.com/windows/internet-explorer/beta/features/accelerators.aspx

Since IE automatically converts search providers to accelerators, we
wanted to allow search providers the ability to provider a PreviewUrl
without having to make an accelerator.

The issue we ran into with trying to use url is that the mime type of
the content is still "text/html" which conflicts with the current use
of that mime type in OpenSearch for displaying results.

It's like we would need another parameter to specific that the use is
for preview, even though the mime type is text/html. Maybe something
like this:

<URL type="text/html" use="preview" template=...>

Is there any such parameter in OpenSearch right now? It may be useful
in other situations as well. For example, if there was such a
parameter then search providers could specify a different url for use
in the search box versus the address bar which could be interesting if
Google wanted to support "I'm feeling lucky.." in the address bar but
regular search from the search box.

thoughts?

-sharon

[Frank Ellermann]

Sharon wrote:

> Maybe something like this:
> <URL type="text/html" use="preview" template=...>

> Is there any such parameter in OpenSearch right now?
> It may be useful in other situations as well. For
> example, if there was such a parameter then search
> providers could specify a different url for use in
> the search box versus the address bar which could be
> interesting if Google wanted to support "I'm feeling
> lucky.." in the address bar but regular search from
> the search box.

AFAIK there is nothing allowing to use the same result
type for different styles of searches at the moment.

And if that is correct simply adding it could confuse
old browsers expecting only one URL per type. Clearly
old browsers would not understand use= and ignore it.

Hacks based on "all old browsers pick the first <Url>"
won't help, that is no proper XML.

IMHO nothing was wrong with your original proposal in
the direction <ie:PreviewUrl>. This is similar to the
<moz:SearchForm> discussion.

Frank

[Sharon]

I see. Good point about backwards compatibility.

I could still see this being useful but perhaps not right now.

-sharon

[Niall Kennedy]

Let's better define PreviewUrl in its Activites context and work
backwards from there.

PreviewUrl is a directly correlated with os:preview [1] and its
os:parameter [2] children to meet the needs of a search Accelerator
service, correct? I see inconsistencies with the implementation of
these two elements within the same namespace. PreviewUrl places the
URL inside the element value while os:preview places the same URL
inside the action attribute.
Recommendation: PreviewUrl should match os:preview while properly
namespaced within an OpenSearch descriptor.

Selection is always type "text" in the OpenSearch case.

A preview search service should return content for display in a 320
pixel width and 240 pixel height 96 dots per inch (dpi) display. All
content outside this region is cut off. According to Accelerator spec
[3].

An OpenSearch descriptor can support multiple languages, defined in
the Language element. The Accelerator can only support a single
language per file [4]. Conflict. Internet Explorer 8 docs recommend
content negotiation on Accept-Language to address this issue.

In summary, the PreviewUrl in a OpenSearch descriptor document would
be used by supporting clients to display a text/html result in a
320x240px frame without overflow with an expectation the remote server
will adapt its content based on Accept-Language. Correct?

-Niall Kennedy


[1] http://msdn.microsoft.com/en-us/library/cc289774.aspx
[2] http://msdn.microsoft.com/en-us/library/cc289773.aspx
[3] http://msdn.microsoft.com/en-us/library/cc289775.aspx#_sz
[4] http://msdn.microsoft.com/en-us/library/cc289775.aspx#_local

[Anil Kumar Ch]

Hi,

How can I make use of "maxWidth" param. Basically, I have 200px image
in my visual suggestion. So, there will not be any space left to
display text/description. I want to increase the width of IE8 Drop
Down box. I gone through http://msdn.microsoft.com/en-us/library/cc848862.aspx#dev_dimensions.
I tried setting maxWidth to some constant in OpenSearch Description
file. But no luck.

Can any one help in this regard?

Thanks & Regards,
Anil Kumar Ch.

[BrandonLive]

In the past my colleagues and I proposed a "rel" attribute be added to
the <Url> parameter for OpenSearch 1.1.

Dewitt and others (on the old e-mail list) seemed to agree and my
understanding was that this would be included in Draft 4 or 5.

Would this not be the ideal way to add the PreviewURL template? It
would look like this:

<Url format="text/html" rel="preview" template="http://foo.com/
searchpreview.aspx?q={searchTerms}"/>

My own project is already using the "rel" attribute with a different
non-search value, in anticipation of this being added to the spec. If
it is not, I will need to move that out into a separate namespace.
But it is a use that would likely be valuable to other clients and so
I think it *should* be part of the standard. I also think that
Suggestions and other data should be returned using a similar
mechanism, as using the "format" attribute is a hack and a misuse in
my opinion.

Brandon

On Oct 1, 4:01 am, Anil Kumar Ch <nil.kumar...@gmail.com> wrote:
> Hi,
>
>  How can I make use of "maxWidth" param. Basically, I have 200px image
> in my visual suggestion. So, there will not be any space left to
> display text/description. I want to increase the width of IE8 Drop

> Down box. I gone throughhttp://msdn.microsoft.com/en-us/library/cc848862.aspx#dev_dimensions.

> > [2]http://www.microsoft.com/windows/internet-explorer/beta/features/inst...
> > [3]http://www.opensearch.org/Specifications/OpenSearch/1.1#OpenSearch_1....
> > [4]http://www.opensearch.org/Specifications/OpenSearch/Extensions/Sugges...- Hide quoted text -
>
> - Show quoted text -