Subject: FYI: Advertising Web services with Atom 1.0

From: James M Snell <[email-masked]>
Date: Fri, 07 Oct 2005 13:27:48 -0700

FYI...

Example of an interesting non-blog use of Atom syndication:

  http://www-128.ibm.com/developerworks/webservices/library/ws-atomwas/

- James

---

From: Aleksander Slominski <[email-masked]>
Date: Fri, 07 Oct 2005 20:53:40 -0500

>  http://www-128.ibm.com/developerworks/webservices/library/ws-atomwas/

it is interesting that atom reader (in this case it seems to 
SharpReader) is actually rendering text content of

|<content type="application/xml">
      <EndpointReference 
      xmlns="http://www.w3.org/2005/08/addressing">
      <Address>http://localhost:9085/wsatom/services/HelloWorld
</Address>
      </EndpointReference>
    </content>|

are atom readers supposed to do that? would it not be better to have a 
proper XHTML as content and store EndpointReference directly as a child 
inside atom:entry? after all EndpointReference  is used by services and 
not Atom GUI apps?

second comment is very difficult (or impossible) to know that feed is 
actually representing "WS introspection" - should there not be there a 
some (optional) element inside atom:feed to indicate that feed contains 
(only) list of EndpointReferences?

best,

alek|
|

-- 
---         Memorable Quote from Firefly (105. Out Of Gas)
-Ship like this, be with you until you die -That's because it's a deathtrap

---

From: "A. Pagaltzis" <[email-masked]>
Date: Sat, 8 Oct 2005 04:29:22 +0200

* Aleksander Slominski <[email-masked]> [2005-10-08 04:00]:
> SharpReader) is actually rendering text content of […] are atom
> readers supposed to do that?

They’re certainly free to. Atom does not dictate what you do
with the bits once you have them, it just tells you what they
mean.

> would it not be better to have a proper XHTML as content and
> store EndpointReference directly as a child inside atom:entry?
> after all EndpointReference  is used by services and not Atom
> GUI apps?

No.

Atom is not a weblog aggregation format.

It can be used in that capacity, and certainly is the finest
choice for that, but that is only one possible use case, and
applications using Atom should not be bent around it.

Putting the EndpointReference in the content is the right thing
to do. Intermediaries and generic Atom stores can trivially pass
it around and/or extract it and delegate it to attached
format-specific processors correctly.

If you put it directly in atom:entry, it becomes a structured
extension element, and then suddenly you have much higher
requirements of your entire infrastructure chain in order to get
the same things done.

> second comment is very difficult (or impossible) to know that
> feed is actually representing "WS introspection"

The namespace of the entries’ contents would be a bit of hint,
no?

> should there not be there a some (optional) element inside
> atom:feed to indicate that feed contains (only) list of
> EndpointReferences?

An extension that allows one to define something like that sounds
like a useful thing to have. (James?)

The right term for this would probably be “role”. Or maybe
“profile”, in the sense that it’s a constrained use of a more
generic format.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

---

From: James M Snell <[email-masked]>
Date: Sat, 08 Oct 2005 07:17:15 -0700

Aleksander Slominski wrote:

> proper XHTML as content and store EndpointReference directly as a 
> child inside atom:entry? after all EndpointReference  is used by 
> services and not Atom GUI apps?
>
If you take another look at the feed generated, I actually put text 
content in the summary element.  Unfortunately, SharpReader seems to 
ignore it in favor of the content.  I think that as a best practice, 
Atom readers should defer to the summary if the content type is anything 
but Text, HTML or XHTML.

> some (optional) element inside atom:feed to indicate that feed 
> contains (only) list of EndpointReferences?
>
I've been considering a profile element that can sit on the feed and 
entry level to indicate this sort of thing.  Essentially, the profile 
element would be used as a key to indicate what kind of feed/entry this 
is. 

For example,
  <feed xmlns="http://www.w3.org/2005/Atom">
     <x:profile>http://example.com/atom/profiles/ws-inspection</x:profile>
     ...
  </feed>

One could easily imagine profile identifiers for blogs, podcasts, news, 
lists (ala netflix queues), etc.

- James

---

From: James M Snell <[email-masked]>
Date: Sat, 08 Oct 2005 07:42:09 -0700

>format-specific processors correctly.
+1

>The namespace of the entries’ contents would be a bit of hint,
Yes, but it would still be helpful to not have to parse the content in 
order to see what's in there.  In this case the content media type is 
not much help given that there is not a specific media type for 
WS-Addressing Endpoint References

>“profile”, in the sense that it’s a constrained use of a more
+1.  this is something I've been thinking about and could likely have 
something drafted up in the come couple of weeks.

- James

---

From: "A. Pagaltzis" <[email-masked]>
Date: Sat, 8 Oct 2005 18:07:46 +0200

* James M Snell <[email-masked]> [2005-10-08 16:45]:
> Yes, but it would still be helpful to not have to parse the
> content in order to see what's in there.

You need to parse it anyway in order to parse the Atom document
as such. With tree-based processing that will have happened
before you even get to the data, too. But even with stream
processing you only need to wait for the start_element event
following that of the atom:content element.

That doesn’t mean I disagree that it would be helpful.

One case where not having a media type is definitely an issue is
with external payloads referenced using atom:content/@src, f.ex.

Regards,

---

From: Aleksander Slominski <[email-masked]>
Date: Sat, 08 Oct 2005 12:56:32 -0500

James M Snell wrote:

>> are atom readers supposed to do that? would it not be better to have 
>> a proper XHTML as content and store EndpointReference directly as a 
> Atom readers should defer to the summary if the content type is 
> anything but Text, HTML or XHTML.

good point. however that also depends on what is the intended use for 
the feed: if it is only used for WS introspection then it is targeted 
for machine processing and maybe administrators that need to see it but 
not ordinary users/developers but there may be some other usage patterns 
where a feed will contain entries mixed with regular blog entries. for 
example xmethods.net could publish not only all service endpoints (WSDL 
or WSA EPRs - and that would be one long list unless feed history is 
used)  but it may as well publish news feed with new services (and their 
associated WSDLs, EPRs, ...)  along with general changes to the website, 
hosting, editorials, etc. such feed would be targeted for developers but 
also easy to use for WS discovery.

>> actually representing "WS introspection" - should there not be there 
>> a some (optional) element inside atom:feed to indicate that feed 
> element would be used as a key to indicate what kind of feed/entry 
> this is.
> For example,
> One could easily imagine profile identifiers for blogs, podcasts, 
> news, lists (ala netflix queues), etc.
>
maybe that should be a special kind of atom:link with 
rel="http://example.rog/Atom/feedType|feedProfile"?

maybe it would be good to allow multiple feed types to apply to one feed 
(or maybe not as it starts to sound like multiple inheritance in OO ...)

best,

alek

---

From: James M Snell <[email-masked]>
Date: Sun, 09 Oct 2005 21:11:40 -0700

Would dc:conformsTo work in this case? 

Aleksander Slominski wrote:

> for machine processing and maybe administrators that need to see it 
> but not ordinary users/developers but there may be some other usage 
> patterns where a feed will contain entries mixed with regular blog 
> entries. for example xmethods.net could publish not only all service 
> endpoints (WSDL or WSA EPRs - and that would be one long list unless 
> feed history is used)  but it may as well publish news feed with new 
> services (and their associated WSDLs, EPRs, ...)  along with general 
> changes to the website, hosting, editorials, etc. such feed would be 
> targeted for developers but also easy to use for WS discovery.
>
>>
>>> second comment is very difficult (or impossible) to know that feed 
>>> is actually representing "WS introspection" - should there not be 
>>> there a some (optional) element inside atom:feed to indicate that 
>>> feed contains (only) list of EndpointReferences?
>>>
> maybe it would be good to allow multiple feed types to apply to one 
> feed (or maybe not as it starts to sound like multiple inheritance in 
> OO ...)
>
> best,
>
> alek
>