Re: OpenSearch RSS

[Robert Sayre]

Tim Bray wrote:
I wonder, is embedding the OpenSearch RSS stuff in Atom going to  cause 
any heartburn?  I'm inclined to think not, but would appreciate  others 
having a look.


I've reviewed this stuff before, and I don't see any barriers to using
this stuff in Atom, other than the extra required elements Atom asks 
for. OTOH, the query spec




says:

  Results

  Search results are expected to be returned in the OpenSearch RSS
  format. For search content providers that do not offer search results
  in OpenSearch RSS format, a wrapper must be authored that can perform
  the transformation.



I get the feeling that OpenSearch + Atom could be real useful.


There is substantial overlap with Atom Protocol paging, especially
existing gregorio-07 implementations. I quite like their approach to URI
construction and their description document, which allows servers to 
place the query parameters anywhere in their URI space.


http://opensearch.a9.com/spec/opensearchdescription/1.0/

They have a read-only protocol, so they don't have to worry about the
relation of state changes to result sets, but it did give me some
simplicity envy when I first read it.

Robert Sayre

Re: OpenSearch RSS

[Bill de hÓra]

Bill de hÓra wrote:


I did the same experiment; bottom line Amazon will need to add
 [...]


Oops, please ignore:


 -atom:modified


[My eyes! The specifications! They do nothing!]

cheers
Bill

Re: OpenSearch RSS

[Bill de hÓra]

Thomas Broyer wrote:


Tim Bray wrote:



Check out A9's OpenSearch at http://opensearch.a9.com/ - I'm starting  
to hear substantial buzz around this thing.


I wonder, is embedding the OpenSearch RSS stuff in Atom going to  
cause any heartburn?  I'm inclined to think not, but would appreciate  
others having a look.


I get the feeling that OpenSearch + Atom could be real useful. -Tim




   * I set type="text/html" on the feed's alternate link, because the
 OpenSearch RSS 1.0 Specification [1] says the RSS  is "a URL
 that can recreate the search in HTML format", @type is not used in
 entries as it might not be text/html
   * I changed the escaped-HTML © to ©, it saves us an
 internal DTD subset while allowing us to use type="text"
   * Atom mandates an atom:author, I added a dummy one
   * Atom mandates an atom:updated in the feed, I added a dummy one; it
 should be set to the latest atom:updated date found in the feed's
 entries, or at least to the date the request was made.
   * Atom mandates an atom:updated in each entry, I added a dummy one;
 it should be set to the last access of the search engine to the
 "result document", or eventually the date the request was made.
 For example, Google is able to give you this date if it has cached
 the document (when you look at a cached page, Google puts a "this
 is Google's cache of  as retrieved on " on top of the page.
   * I used the address of the "result document" (permalink?) as the
 atom:id of each entry, because this is the easiest way to do it...


I did the same experiment; bottom line Amazon will need to add

 -atom:updated
 -atom:id
 -atom:modified
 -a few attributes

to use Atom. They also need to fix their example*, it's invalid XML 
(© in the last entry). By the looks of things, with the feed level 
extensions, they're going the route Nature have taken with RSS1.0.


cheers
Bill

* http://opensearch.a9.com/spec/opensearchrss/1.0/

Re: OpenSearch RSS

[Thomas Broyer]

Tim Bray wrote:



Check out A9's OpenSearch at http://opensearch.a9.com/ - I'm starting  
to hear substantial buzz around this thing.


I wonder, is embedding the OpenSearch RSS stuff in Atom going to  
cause any heartburn?  I'm inclined to think not, but would appreciate  
others having a look.


I get the feeling that OpenSearch + Atom could be real useful. -Tim

Just to see how it would look like, this is what the search result 
example [1] would be in Atom:

http://a9.com/-/spec/opensearchrss/1.0/";>
A9.com Search: New York City history
tag:A9.com,2005:New%20York%20City%20history
http://a9.com/New%20York%20City%20history"; />
Search results for "New York City history" at 
A9.com

© 2003-2005, A9.com, Inc. or its affiliates.

  A9.com, Inc.
  http://a9.com/

2005-05-30T23:50:00+02:00
423
1
10


  New York City History
  http://www.columbia.edu/cu/lweb/eguides/amerihist/nyc.html"; />
  
http://www.columbia.edu/cu/lweb/eguides/amerihist/nyc.html

  2005-05-30T00:00:00+02:00
  ... Harlem.NYC - A virtual tour and information on 
businesses ... with historic photos of Columbia's own New York 
neighborhood ... Internet Resources for the City's History. 
...



  Gotham Center for New York City History
  http://www.gothamcenter.org/"; />
  http://www.gothamcenter.org/
  2005-05-30T00:00:00+02:00
  ... Submit Events Edit Your Submission. Main 
Neighborhood Stories NYC History in the ... The Gotham Center for New 
York City History is supported by The CUNY Graduate ...




  Welcome to the Museum of the City of New York
  http://www.mcny.org/"; />
  http://www.mcny.org/
  2005-05-30T00:00:00+02:00
  ... a list with the event staff. Additional information 
will be included in the confirming email. © Museum of the City of 
New York.




Some comments:

   * I set type="text/html" on the feed's alternate link, because the
 OpenSearch RSS 1.0 Specification [1] says the RSS  is "a URL
 that can recreate the search in HTML format", @type is not used in
 entries as it might not be text/html
   * I changed the escaped-HTML © to ©, it saves us an
 internal DTD subset while allowing us to use type="text"
   * Atom mandates an atom:author, I added a dummy one
   * Atom mandates an atom:updated in the feed, I added a dummy one; it
 should be set to the latest atom:updated date found in the feed's
 entries, or at least to the date the request was made.
   * Atom mandates an atom:updated in each entry, I added a dummy one;
 it should be set to the last access of the search engine to the
 "result document", or eventually the date the request was made.
 For example, Google is able to give you this date if it has cached
 the document (when you look at a cached page, Google puts a "this
 is Google's cache of  as retrieved on " on top of the page.
   * I used the address of the "result document" (permalink?) as the
 atom:id of each entry, because this is the easiest way to do it...

I've put this document online [2], with the "Atom 0.3" namespace URI 
(http://purl.org/Atom/ns#)


Note that the OpenSearch RSS 1.0 Specification [1] forbids the use of 
escaped HTML in many elements. If there were an "OpenSearch Atom", it 
could also be limited to type="text" (and/or type="xhtml", because it's 
quite easy to transform XHTML to plain text), though A9.com website 
(which acts as an reader/aggregator for OpenSearch RSS documents) would 
then not be a valid Atom Processor.


The OpenSearch Description Document [3] would /a priori/ be the same 
(except of course that it would use a different value in the "Format" 
element to indicate "OpenSearch Atom" instead of "OpenSearch RSS".


The Atom result document could also link to the next and previous 
"pages" with additional atom:link elements in the atom:feed, with 
"extended" @rel values.


[1] http://opensearch.a9.com/spec/opensearchrss/1.0/
[2] http://www.ltgt.net/atom/opensearch.atom
[3] http://opensearch.a9.com/spec/opensearchdescription/1.0/

--
Thomas Broyer

OpenSearch RSS

[Tim Bray]

Check out A9's OpenSearch at http://opensearch.a9.com/ - I'm starting  
to hear substantial buzz around this thing.


I wonder, is embedding the OpenSearch RSS stuff in Atom going to  
cause any heartburn?  I'm inclined to think not, but would appreciate  
others having a look.


I get the feeling that OpenSearch + Atom could be real useful. -Tim

Re: atom, xslt processors (Re: atom:type, xsl:output)

[James Cerra]

Aristotle,

> > > Why do you think it is appropriate to have a random PI
> > > processor in between the XML processor and the Atom
> > > processor?
> > 
> > Because the XML is just the grammar serializing the ontology,
> > or data structure, of interest. I see Atom processors as
> > normally the Bridge between the XML document and the particular
> > CMS, IA, or web browser application's internal structure. So
> > an Atom processor would be the last stage before the data is
> > internalized. The intent of _Processing_ Instructions seems to
> > change how the document is processed. That implies to me that
> > they would probably be interpreted between the XML processor
> > and the particular grammar's processor.
> 
> Atom is a transport envelope for potentially a multitude of
> documents. Saying that the enveloped documents should be
> preprocessed before they are unfolded from the envelope is like
> saying that a part of a multipart/mime document which has a
> “Content-Encoding: gzip” header should be uncompressed in situ
> *before* it is extracted from the multipart envelope.

Note that by "change how the document is processed" I mean the Atom document -
i.e. the envelope - not the content of atom:content - the enveloped document. 
Sorry for my imprecise language.  So PIs change how the Atom document is
processed.  Could you give an example of how they would be clearly associated
with the enveloped document (which counters this argument)?



--
Jimmy Cerra
https://nemo.dev.java.net

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: atom:type, xsl:output

[James Cerra]

Aristotle,

> > > >> Depending on an entity reference and not being able to
> > > >> accept the straight replacement text is just wrong.
> > > >
> > > > I agree.  I'm just bringing up possible incompatibilities
> > > > for debate!
> > > 
> > > I don't think that's an incompatibility that deserves
> > > catering for.
> > 
> > Why not?  Why be incompatible for the sake of incompatibility?
> > That's just asking for trouble when Atom is used in ways not
> > originally envisioned (and there always are).
> 
> That’s bogus. Some software generates or processes non-wellformed
> XML. Should Atom cater to that too? If not, where do you draw the
> line between somewhat-broken software that Atom should support
> and really-broken software that it should not?

Depends on the situation.  :-)

I think that Atom should support specifying doctypes since there're in the XML
spec and are well-formed constructs (even if external subsets are not read). 
I'd like Atom to support having _all_ well-formed XML documents be possible
atom:content (referenced by @src at least).

> > HTML currently uses doctypes for switching between versions of
> > the langauage.
> 
> No, it doesn’t. Browsers do so, but only as a hack; the idea is
> that an author who puts a DOCTYPE declaration in their document
> *probably* cares about validity and so his document should
> *probably* be treated as strict standards compliance requires.
> But there is nothing in any spec that justifies this behaviour.

How do you differentiate between XHTML 1.0 Strict and XHTML 1.0 Transitional
without doctypes?

> > There is no other way to properly interpret content without
> > guessing in the current drafts.  That is a worse sin inflicted
> > upon programmers, than allowing the subset that do rendering to
> > do naughty DOCTYPE sniffing.
> 
> You don’t seem to understand XML. XML has something called
> namespaces. Use them.

I understand XML and namespaces.  Lets keep the personal attacks out of this
thread, and not start a flame war, OK?

The problem is that there are specs which use one namespace for several
versions!

> > > > No, any well formed XML processor MUST expand internal
> > > > entities and add replaced attributes as well.  This is NOT
> > > > OPTIONAL.
> > > 
> > > So is expat non-conforming?
> > 
> > If it doesn't, then it is non-conforming.
> 
> Wrong.
> 
> > That's how non-validating XML processors are defined by the
> > spec.  I quote from section 5.1 paragraph 4:
> > 
> > [Definition: While they are not required to check the document
> > for validity, they are REQUIRED to process all the declarations
> > they read in the internal DTD subset and in any parameter
> ^^
> > entity that they read, up to the first reference to a parameter
>  ^^
> > entity that they do not read; that is to say, they MUST use the
>  ^
> > information in those declarations to normalize attribute
> > values, include the replacement text of internal entities, and
> > supply default attribute values.]
> > 
> > There is no room for any other interpretation, I think.
> 
> Nowhere is a non-validating processor REQUIRED to read an
> external DTD in the spec. Only *internal* declarations MUST be
> processed and references resolved.

Um, I was talking about internal declarations!  Non-validating processors are
required to read the external subset declaration (but they don't have to
resolve and parse it) and the internal subset up to any paramater references
they don't read.  So in the following declaration everything must be read
except for anything in the external file:

http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"; [
  
]>

A non-validating processor will report the public and system ids as well as
processing the entity declaration.  Since the declaration of the external
subset is used, in this case, to change semantics of the XHTML elements
(namely, which version of the standard they conform to).



--
Jimmy Cerra
https://nemo.dev.java.net



__ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new Resources site
http://smallbusiness.yahoo.com/resources/

Re: atom, xslt processors (Re: atom:type, xsl:output)

[Paul Hoffman]

At 4:54 PM +0200 5/30/05, A. Pagaltzis wrote:

Atom is a transport envelope for potentially a multitude of
documents. Saying that the enveloped documents should be
preprocessed before they are unfolded from the envelope is like
saying that a part of a multipart/mime document which has a
"Content-Encoding: gzip" header should be uncompressed in situ
*before* it is extracted from the multipart envelope.

That doesn't make any sense.


+1

--Paul Hoffman, Director
--Internet Mail Consortium

Re: atom, xslt processors (Re: atom:type, xsl:output)

[A. Pagaltzis]

* James Cerra <[EMAIL PROTECTED]> [2005-05-30 02:35]:
> For a counter example: For internal use I might create an Atom
> feed from atom entries with  attached to
> either the feed or the entries. Furthermore, I could add
> instructions for my stylesheet by defining PIs used in the
> entries. In this case, the PI processor is an xslt processor
> that works before the atom processor. The original contains
> global options and defines the template, while the entries are
> parsed and aggregated into the original file. This way it is
> easier to change the feed's options without editing the XSLT
> source files. The atom processor becomes the last stage in the
> pipe.

So you expect every XML processor to have an XSLT processor
attached so that it will be able to resolve your custom Atom+PIs
superformat to regular Atom?

Regards,
-- 
Aristotle

Re: atom, xslt processors (Re: atom:type, xsl:output)

[A. Pagaltzis]

* James Cerra <[EMAIL PROTECTED]> [2005-05-30 02:00]:
> > Why do you think it is appropriate to have a random PI
> > processor in between the XML processor and the Atom
> > processor?
> 
> Because the XML is just the grammar serializing the ontology,
> or data structure, of interest. I see Atom processors as
> normally the Bridge between the XML document and the particular
> CMS, IA, or web browser application's internal structure. So
> an Atom processor would be the last stage before the data is
> internalized. The intent of _Processing_ Instructions seems to
> change how the document is processed. That implies to me that
> they would probably be interpreted between the XML processor
> and the particular grammar's processor.

Atom is a transport envelope for potentially a multitude of
documents. Saying that the enveloped documents should be
preprocessed before they are unfolded from the envelope is like
saying that a part of a multipart/mime document which has a
“Content-Encoding: gzip” header should be uncompressed in situ
*before* it is extracted from the multipart envelope.

That doesn’t make any sense.

Regards,
-- 
Aristotle

Re: atom:type, xsl:output

[A. Pagaltzis]

* James Cerra <[EMAIL PROTECTED]> [2005-05-30 03:20]:
> > >> Depending on an entity reference and not being able to
> > >> accept the straight replacement text is just wrong.
> > >
> > > I agree.  I'm just bringing up possible incompatibilities
> > > for debate!
> > 
> > I don't think that's an incompatibility that deserves
> > catering for.
> 
> Why not?  Why be incompatible for the sake of incompatibility?
> That's just asking for trouble when Atom is used in ways not
> originally envisioned (and there always are).

That’s bogus. Some software generates or processes non-wellformed
XML. Should Atom cater to that too? If not, where do you draw the
line between somewhat-broken software that Atom should support
and really-broken software that it should not?

> HTML currently uses doctypes for switching between versions of
> the langauage.

No, it doesn’t. Browsers do so, but only as a hack; the idea is
that an author who puts a DOCTYPE declaration in their document
*probably* cares about validity and so his document should
*probably* be treated as strict standards compliance requires.
But there is nothing in any spec that justifies this behaviour.

> There is no other way to properly interpret content without
> guessing in the current drafts.  That is a worse sin inflicted
> upon programmers, than allowing the subset that do rendering to
> do naughty DOCTYPE sniffing.

You don’t seem to understand XML. XML has something called
namespaces. Use them.

> > > No, any well formed XML processor MUST expand internal
> > > entities and add replaced attributes as well.  This is NOT
> > > OPTIONAL.
> > 
> > So is expat non-conforming?
> 
> If it doesn't, then it is non-conforming.

Wrong.

> That's how non-validating XML processors are defined by the
> spec.  I quote from section 5.1 paragraph 4:
> 
> [Definition: While they are not required to check the document
> for validity, they are REQUIRED to process all the declarations
> they read in the internal DTD subset and in any parameter
    ^^
> entity that they read, up to the first reference to a parameter
 ^^
> entity that they do not read; that is to say, they MUST use the
 ^
> information in those declarations to normalize attribute
> values, include the replacement text of internal entities, and
> supply default attribute values.]
> 
> There is no room for any other interpretation, I think.

Nowhere is a non-validating processor REQUIRED to read an
external DTD in the spec. Only *internal* declarations MUST be
processed and references resolved.

Regards,
-- 
Aristotle

Re: Problem with Metadata Elements (section 6.4)

[Thomas Broyer]

David Powell wrote:
>
> Quoting Thomas Broyer:
>
>> The problem come when I use a "plain flowed text" and can then omit
>> the "type" attribute:
>> By Thomas Broyer and al.
>> My extension becomes a Simple Extension Element when processed by an
>> Atom Processor, and an Atom Processor having some "generic support"
>> for Simple Extension Elements (which is really the intent of SEE)
>> would change its behavior when processing it, which is not really
>> wanted.
>> However, I don't think I badly designed the byline extension, or this
>> would imply that Atom itself is badly designed (and I don't think so).
>
> I don't think that this is a big problem.  The allowed syntax of
> Structured Extension Elements is defined by the designer of the
> Structured Extension.  It is the designer's responsibility to ensure
> that Structured Extensions don't flip into being Simple Extensions, so
> they need to be designed in a way such that they have at least one child
> element or attribute.
>
> In this case the easiest way to do this would be to make @type mandatory
> even when @type="text" is required.

Of course yes, but the extension then doesn't follow the same rules as
Text Constructs, which are part of Atom, and it's bothering me. If I can't
design my extensions in the same way Atom designed its markup, I think
there is a problem... That's why I think the Metadata Elements (Simple and
Structured Extension Elements) wording is too strong in the spec.

The intent is (should be) to give a hint to Atom implementors providing
generic support for "name/value pair" properties and to extension
designers, not to enforce a particular behavior.

Changing that would also throw away your problem (discussed offlist) with
later allowing (e.g. in Atom 1.1) Metadata Elements in Atom elements where
foreign markup is today just "foreign markup", without any defined role.
To summarize for other people on the list, David's problem was that if we
don't define a role today for foreign markup inside Atom elements other
than atom:feed, atom:entry, Person Constructs and atom:source, e.g. inside
atom:link, then we wouldn't be able to define it later, because foreign
markup that would have been used with Atom 1.0 don't necessarily follow
the rules of section 6.4 and therefor won't be ok if Atom 1.1 says that
atom:link's foreign markup children are now considered Metadata Elements.

--
Thomas Broyer

Re: Problem with Metadata Elements (section 6.4)

[David Powell]

Quoting Thomas Broyer <[EMAIL PROTECTED]>:

> The problem come when I use a "plain flowed text" and can then omit the
> "type" attribute:
> By Thomas Broyer and al.
> My extension becomes a Simple Extension Element when processed by an Atom
> Processor, and an Atom Processor having some "generic support" for Simple
> Extension Elements (which is really the intent of SEE) would change its
> behavior when processing it, which is not really wanted.
> However, I don't think I badly designed the byline extension, or this
> would imply that Atom itself is badly designed (and I don't think so).

I don't think that this is a big problem.  The allowed syntax of Structured
Extension Elements is defined by the designer of the Structured Extension.  It
is the designer's responsibility to ensure that Structured Extensions don't
flip into being Simple Extensions, so they need to be designed in a way such
that they have at least one child element or attribute.

In this case the easiest way to do this would be to make @type mandatory even
when @type="text" is required.

--
Dave

Problem with Metadata Elements (section 6.4)

[Thomas Broyer]

I was discussing extensions offlist with Dave Powell and came to explain
what I previously said on the list about Simple/Structured Extension
Elements [1] when I thought I found a real problem with that.

There have been much discussion last weeks about authors, contributors and
bylines and bylines were rejected to extensions (and I'm +1 on that,
that's not the point). So imagine I want to create such a byline
extension.

Ideally, I'd like it to be text that can be enriched with some markup. The
obvious choice here is to reuse the Text Construct mechanism: it is
already implemented in every Atom Processor so adding support for my
byline extension would be made much easier than redefining a different
mechanism, and of course it is homogeneous with Atom so better for users.

So my ext:byline element MAY have a "type" attribute with value "text",
"html" or "xhtml". When not present, it defaults to "text". Depending on
the  "type" attribute's value, the content is "plain flowed text", escaped
HTML or an XHTML div.

My byline extension then looks like the following, and is obviously a
Structured Extension Element (as it comes in atom:feed, atom:entry or
atom:source):
By Thomas Broyer and al.
By Thomas
Broyer and al.

  By http://www.ltgt.net/";>Thomas Broyer and al.


The problem come when I use a "plain flowed text" and can then omit the
"type" attribute:
By Thomas Broyer and al.
My extension becomes a Simple Extension Element when processed by an Atom
Processor, and an Atom Processor having some "generic support" for Simple
Extension Elements (which is really the intent of SEE) would change its
behavior when processing it, which is not really wanted.
However, I don't think I badly designed the byline extension, or this
would imply that Atom itself is badly designed (and I don't think so).

Are other people here seeing a problem with Simple vs. Structured
Extension ELements or am I the only one?

[1] http://www.imc.org/atom-syntax/mail-archive/msg15751.html

-- 
Thomas Broyer