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.
