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? 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.
cheers,
dret.
