> I'm still not convinced that there would be that many schemas in
> practice - for a book, for example we would need Mods, book-fulltext,
> chapter-fulltext, section-fulltext, sentence-fulltext (and that may be
> too long a list).
.. page-fulltext, line-fulltext, folio-fulltext, column-fulltext,
quire-fulltext, rubric-fulltext, paragraph-fulltext ... need I go on?
And that's just for TEI like full text documents, let alone all the other
Multipy the number of schemas by the number of applications using them by
the number of different displays the application needs that aren't simple
DC or the complete record. That's a Big Number. I can't think of all the
ways that a client might want to use my data. With XPath I don't need to.
> > Here's one closer to home for you: An XML representation of a musical
> > score. Return the trumpet section. Return the first 4 bars.
> have to know there is a trumpet section etc.
As opposed to having to design a new schema, get the server developer to
support the new schema, then getting the individual server maintainer to
upgrade to the new version (possibly having to pay to do so). Obviously
coping with a diagnostic is much harder than that for client developers.
I find the argument extremely weak, sorry. Especially as you'll have to
deal with diagnostics saying that the server doesn't support the schema
> I'm more likely to return the Mods record for the item with a link to
> the data, than the data intact (or at least support
Very 1990s, don't you think? Can't handle the data properly so ... I'll
just give you a link to it and hope that the client can somehow deal with
it. Why don't we do this for all of our records? That would make life
much easier if the only contents of recordData was a URL to the record.
The world has moved on from this model, IMO, and not being able to
gracefully cope with large records is going to be an increasingly
significant failing. -Everything- is going XML, for better or worse, and
XML isn't a compact data format. Having to return only short metadata
records is, again IMO, an extremely short sighted decision that will
hinder take up worse than a single, optional, parameter that references a
well defined, well understood and broadly implemented standard.
But, I've registered my proposal, people apart from Mike think it's
somehow too complex even though it's expainable in a single sentence, so
I'll just have to assign namespaces for all the different schemas I need.
Probably in the form:
,'/:. Rob Sanderson ([log in to unmask])
,'--/::(@)::. Special Collections and Archives, extension 3142
,'---/::::::::::. Nebmedes: telnet: nebmedes.o-r-g.org 7777
____/:::::::::::::. WWW: http://nebmedes.o-r-g.org:8000/
I L L U M I N A T I