2011/3/31 justinsb <email address hidden>:
> The fact is, we are supposed to be supporting this API.
Right. So this should be referenced from a blueprint or something.
Documentation should document how things *are*, not how we wish they were.
> This is the spec
> for our "v1.0" endpoint. While XML can be fugly, it does have the benefit
> of being an excellent spec for the wire format, which it's easy to test
> against. Most of the specs carry across to our JSON output. If we want our
> API to be compatible with the many existing tools out there that talk to the
> CS API, this is the spec we have to validate against.
I completely agree, so if these schemas were used for this validation,
I'd be perfectly happy with it.
> I think the right thing to do is to merge these specs, on the ground that
> they are the best specs we've got for what we're supposed to be targeting
2011/3/31 justinsb <email address hidden>:
> The fact is, we are supposed to be supporting this API.
Right. So this should be referenced from a blueprint or something.
Documentation should document how things *are*, not how we wish they were.
> This is the spec
> for our "v1.0" endpoint. While XML can be fugly, it does have the benefit
> of being an excellent spec for the wire format, which it's easy to test
> against. Most of the specs carry across to our JSON output. If we want our
> API to be compatible with the many existing tools out there that talk to the
> CS API, this is the spec we have to validate against.
I completely agree, so if these schemas were used for this validation,
I'd be perfectly happy with it.
> I think the right thing to do is to merge these specs, on the ground that
> they are the best specs we've got for what we're supposed to be targeting