I'm all in favor of discarding the simpler of the two (as I've probably made quite clear already). Your point about interoperability is certainly valid.
I think we've amply demonstrated the need for the more complex form. And there should not be an interoperability problem - servers will indicate which schemas they support via explain, and we now have a simple mechanism to indicate whether a schema is supported for record data or metadata or both (the dual id) so these can be exposed via explain.
So why don't we just agree to drop the simpler form?
--Ray
----- Original Message -----
From: Mike Taylor
To: [log in to unmask]
Sent: Thursday, May 17, 2007 6:41 PM
Subject: Revised record metadata proposal
Ray Denenberg, Library of Congress writes:
> I have revised the record metadata proposal:
> http://www.loc.gov/standards/sru/metadata.html
Thanks.
> Notes:
>
> - This references a new record metadata schema, called "rmd". We
> decided during this discussion that "rec" was a misleading name, so
> I renamed it. It can be based on rec or rewritten. We'll discuss
> this among the Ed. Board.
OK.
> - This page describes both how to retrieve record metadata the
> "conventional" way, and by extension, as we discussed. The
> "conventional" discussion is included for completeness.
Good. This section is nice and clear.
> - Two extensions are defined. One is the simple extension with no
> parameter value that assumes the default schema (rmd) and the
> second allows a schema name to be supplied. This is a compromise,
> as it is clear that there are two postions on this and that the
> advocates on both sides are pretty well dug in. In any case there
> is a justification supplied for two extension ("Reason for two
> extentions") which I think makes a compelling argument.
Hmm, now, what would be a nice, polite way to respond to this? Oh,
yes, I know, got it: SOMEONE MAKE THE MADNESS STOP!
:-)
My objection to the more complex version of the extension, in which
any schema may be requested, was that it would reduce interoperability
by creating situations in which both client and server would conform
to the specification but still be unable to cooperate. Introducing a
whole alternative extension makes this problem far worse still: a
client might implement one version and but its server the other.
If there is general agreement that we need the more complex form of
the extension, than can we please have that and only that version, and
discard the simpler version completely?
_/|_ ___________________________________________________________________
/o ) \/ Mike Taylor <[log in to unmask]> http://www.miketaylor.org.uk
)_v__/\ "Don't give me that, you snotty-faced heap of parrot droppings"
-- Monty Python's Flying Circus.
