[mdx] what to trust
Ian Young
ian at iay.org.uk
Tue May 5 10:10:34 PDT 2009
On 5 May 2009, at 16:37, Josh Howlett wrote:
>> I guess we
>> could fix that by (in the new publishing
>> protocol) always wrapping single entity documents in a
>> separate EntitiesDescriptor, but that sounds pretty unpleasant too.
>
> Is it the redundancy that you find unpleasant? IMO, it seems like a
> reasonable price to pay...
I think I expected (and I think it's natural to expect) that an API,
particularly a RESTian one, would just return the EntityDescriptor
when you explicitly request an entity by name.
http://blah.blah/root/url returns entire aggregate as
EntitiesDescriptor
http://blah.blah/root/url/entity/foo returns one entity, as
EntityDescriptor
I don't want to add complexity to cover some case that will be hard to
explain.
On the other hand, maybe the ask-for-an-entity-get-back-an-entity
model isn't the right one. It's probably less of a stretch to regard
all results as potentially multi-valued if we're thinking of adding
some kind of query-by-tag as well as just the cases we originally
thought of. It's more capable of being generalised in the future to
other kinds of query, too.
[I think it might also allow us to preserve an existing signature on
the EntityDescriptor, from whatever source. Given the brittleness of
XML DSIG that might not be realistic, even if we could think of a
reason it might be desirable. That inner signature would in any case
break if anyone did any transformation on the EntityDescriptor's
contents whatsoever, which I'd expect would be happening quite
frequently in practice.]
In other words, perhaps the way to spin this is saying that
"everything comes back as an EntitiesDescriptor" is analogous to what
you get back from something like an SQL query... you get back a row-
set even in cases where you know in advance it will only have one
thing in it.
One thing this approach doesn't help you with is the "no results"
case; you still need to be able to say "no answer" in some way other
than returning an EntitiesDescriptor with no contained
EntityDescriptors, because that isn't schema-valid.
Scott might like to comment on whether using the @Name in this way (as
the name of the group of entities of which the contained entities are
a part, instead of as the name of the group of entities contained) is
out of line with respect to the relevant spec. To wording seems to
allow for things to mean whatever a deployment wants them to, but I
guess I might be choosing to read that section with more flexibility
than intended.
-- Ian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2448 bytes
Desc: not available
URL: <http://lists.iay.org.uk/pipermail/mdx-iay.org.uk/attachments/20090505/9393162c/attachment-0002.bin>
More information about the mdx
mailing list