fair enough! keep me(us) posted. thanks
-Toru On 5/4/06, James M Snell <[EMAIL PROTECTED]> wrote:
This is the type of thing that is perfect for namespaced extensions to the introspection document and not for the core vocabulary. I've already been kicking around this kind of mechanism as an extension. Perhaps at some point after the core spec is completed, this is something we can work on collaboratively. - James Toru Marumoto wrote: > On 5/3/06, James M Snell <[EMAIL PROTECTED]> wrote: >>> Toru Marumoto wrote: >> > Is the value of "app:accept" element extensible? >> > Let's say I extended the Atom Entry Document using my own namespace. >> > Then, Is this (below) appropriate thing to do? >> > <accept>entry,MyExtendedEntry</accept> >> > >> No, the listing in accept is *only* a listing of media ranges and/or the >> "entry" label and determines only what kinds of representations may be >> POSTed to the collection. It does not differentiate between different >> types of entries. > > Right.. I should use atom:category to differentiate entry kinds, I guess. > > What about extensions, though. It would be great if there is a way to > indicate > what extension is acceptable(understandable) to a collection, kind of > like XML-RPC API's mt.supportedMethods. > I'm pretty sure there will be a lot of extensins such as "blog entry with > trackback extension","blog entry with readmore extension", "blog entry > with scheduled post extension" etc. > APP clients probably need to know before they attempt to actually > post an extended atom entry. > > so how about something like... > > <accept class="entry,application/atom+xml" readonly="false"> > <extension namespace="http://purl.org/hoge";>MyExtension</extension> > <extension namespace="http://schemas.google.com/g/2005";>gd</extension> > </accept> > > If you omit <accept /> entirely, then default is <accept class="entry" > readonly="false" />. > > > ok, please ingnore above example.... somebady help me out please. >
