Another point, I do not believe anyone is actually doing this, but it
would be entirely possible to combine RSD and the Atompub service doc.
RSD would basically become and extension within the service doc. Doing
so would give clients that support multiple api's one place to look for
everything.
<service xmlns="http://www.w3.org/2007/app";>
...
<rsd:service xmlns:rsd="...">
<rsd:engineName>Legacy Interfaces</rsd:engineName>
<rsd:engineLink>...</rsd:engineLink>
<rsd:apis>
<rsd:api name="MetaWeblog" apiLink="..." blogID="..." />
...
</rsd:apis>
</rsd:service>
...
</rsd:service>
- James
Joe Cheng wrote:
> On that note... Windows Live Writer supports both RSD/MetaWeblog and Atom. Since our Atom support is brand new while our RSD/MetaWeblog code has been tested in the field, when both RSD and Atom service links are present in a page, we'll be using the RSD.
>
> If you have both RSD and Atom, and you want WLW to work with Atom (Dave Johnson, I'm looking in your direction!) then add class="preferred" to the service doc link. (Credit for this idea goes to Mr. Snell; my original solution was much uglier!) e.g.:
>
> <link rel="service" class="preferred" type="application/atomsvc+xml" href="..." />
>
> If anyone has feedback about this approach, I would love to hear it. Hopefully as time goes by and Atom implementations catch up in features and real-world experience, we can switch to Atom as the default.
> ________________________________________
> From: owner-atom-protocol@xxxxxxxxxxxx [owner-atom-protocol@xxxxxxxxxxxx] On Behalf Of James M Snell [jasnell@xxxxxxxxx]
> Sent: Thursday, August 30, 2007 7:34 PM
> To: Michael Wechner
> Cc: Paul Denning; atom-protocol@xxxxxxx; uddi-spec@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: Discovery of APP service documents
>
> For Lotus Connections we use a link element in the head of an (x)html page.
>
> <link rel="service" type="appliation/atomsvc+xml" href="..." />
>
> Windows Live Writer and others have implemented support for it.
>
> - James
>
> Michael Wechner wrote:
>> Paul Denning wrote:
>>
>>> [1]
>>> http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-17.txt
>>>
>>> Section 8 of [1] states
>>>
>>> "How Service Documents are discovered is not defined in this
>>> specification."
>>>
>>> Is anyone working to define one or more ways of discovering service
>>> documents?
>>
>> sorry if I might be getting a bit off-topic, but could you outline a
>> real-world use-case which you have in mind?
>>
>> Thanks
>>
>> Michael
>>
>>>
>>> Note, I have proposed a taxonomy for use in UDDI that would allow a
>>> categoryBag to include a MIME type [2].
>>> This would enable registration in UDDI of anything with a MIME type,
>>> such as, APP service documents.
>>>
>>> [2] http://del.icio.us/mitrepauld/mime+uddi
>>>
>>> Since APP service documents use "application/atomsvc+xml", using this
>>> as a keyValue in a tModel is one way to register APP service documents
>>> in UDDI. Obviously, then you could use UDDI find_tModel to discovery
>>> those tModels. The overviewURL would point to the service document.
>>>
>>> For example,
>>>
>>> <tModel tModelKey="uddi:a762aed0-571e-11dc-89c4-391cf3b1899c"
>>> xmlns="urn:uddi-org:api_v3">
>>> <name>Atom Publishing Protocol Service Document</name>
>>> <overviewDoc>
>>> <overviewURL
>>> useType="tbd">http://example.org/my-app-service-doc</overviewURL>
>>> </overviewDoc>
>>> <categoryBag>
>>> <keyedReference
>>> tModelKey="uddi:iana.org:taxonomy:media-types"
>>> keyName="Atom Publishing Protocol Service Document"
>>> keyValue="application/atomsvc+xml"/>
>>> </categoryBag>
>>> </tModel>
>>>
>>> Notes:
>>> 1. Use of the tModelKey "uddi:iana.org:taxonomy:media-types" is
>>> suggested, but has not been coordinated with IANA.
>>> 2. useType in the example above is "tbd". UDDI v3.0.2, section B.2,
>>> discusses the useType attribute within the overviewURL element.
>>> useType="text" could suffice, or some other value can be used. For
>>> example, section B.8 of the UDDI spec RECOMMENDS using another
>>> tModelKey to effectively register the new useType in UDDI. IANA does
>>> not provide a UDDI registry where such "well-known" keys can be
>>> documented. OASIS has a process for registration of well-known
>>> tModels on the web [3].
>>>
>>> [3] http://uddi.xml.org/tmodels
>>>
>>> A similar technique for discovery of RSS feeds using UDDI was
>>> suggested [4], but not used much in practice as far as I can tell.
>>>
>>> [4] http://winfx.members.winisp.net/karstenj/docs/rss_in_uddi.aspx
>>>
>>> Paul
>>>
>>>
>>
>
>