RE: We can't use RSD

["Danny Ayers" <danny666@xxxxxxxxxxx>]

> It is somewhat more verbose, but it also allows for the
> possibility of an engine supporting more than one API. Start
> adding that to the introspection file and they'll even out almost
> entirely...

Well, not necessarily - the addition could be a simple as inserting a
namespace qualified element :

<otherapi:speakingText>http:///mysite.org.org/getspeech</otherapi:speakingTe
xt>

> It might be another conversation for elsewhere, but there doesn't
> seem to be any limitation on what can be returned in an
> introspection file... I quote the current version of the RFC
> "Additionally, new facets may be added either through vendor
> extension or follow-on RFCs." yet there's nothing that says that
> vendor extensions need to be namespaced, or whether they can
> simply include new elements in the introspection space and
> ignored by clients that do not understand them or whatever...

Yep, but it is still early days...

> > Personally I'd rather see
> > something written from scratch for consistency, but if we're
> going to use an
> > existing standard we might as well use one of the more
> generally deployed
> > service description formats such as WSDL. Blogging might be an
> island now,
> > but it won't remain so forever.
>
> The other formats are least as stylistically diverse and verbose
> as RSD, so they offer the same "compromise" to use your term.

Yes, indeed they do. Also different pros and cons in each case.

> Whether they are better choices is, I guess, a different conversation.

Same conversation, probably a different subject line ;-)

Did we ever have a poll at the level of :

 "How do we do service discovery/description?"

1. Something new (AtomAPI 0.7)
2. RSD
3. WSDL
4. RDF
5. RDDL
6. Other

?

Cheers,
Danny.