Re: AtomPub accept

[Jan Algermissen <algermissen1971@xxxxxxx>]

On Aug 26, 2010, at 3:23 AM, Erik Wilde wrote:

> hello jan.
> 
>>> still requires some rather static "registration" of those profile names, right? 
>> Yes, that is the idea :-) ... it is all about avoiding coupling clients to specific services. Better to couple to a 'standard'.
> 
> my 2min research did not yield a conclusive answer to this, but it is actually possiblt to define a parameter to a media type when the media type is already existing and does not have that parameter?

The rule should be (though I have no pointer) to ignore unknown parameters. So, it would be fine.

> it kind of feels weird, but my media type definition/registration knowledge is a bit rusty in this particular department...
> 
>>> or could these be any kind of resource, including something like schemas or templates that would be fully self-describing?
>> IMHO anything will do as long as the specification is a 'standard' (in the sense of: not specific to the single service) and as long as it enables developers to use the specification when implementing the client and server. IOW: developers must understand it
> 
> a schema would be nice because it could be machine-readable, so that there would be no need to have a predefined set of profile values. you find a profile URI, read the schema, and then know what additional constraints are defined for the KML mathing this profile. probably ok, but i am a bit concerned about the retrofitting of parameters.
> 
>>> client behavior, generally speaking ;-) specifically, our UI should only provide tools to create features that then are accepted, so that users don't get a UI that allows them to create polygons, only to have them rejected by the server. our work revolves around managing spatial objects using atom and atompub.
>> Curious due to some other discussions I have been having: Why did you not use HTML to drive your user agent?
> 
> because we are building a feed-oriented API where the main abstraction are KML-described spatial features, and those are exposed through a specialization of the general atom/atompub API to collections. for our scenario, i wouldn't even know ho9w we could utilize HTML.

I was just asking because I had the impression you have a completely human targeted user agent.

Is there anything in public to read that explains what you are building?

Jan



> 
> cheers,
> 
> dret.