This use case can be implemented with a server side transformation
producing the stand alone TEIheader before sending the OAI response (I
did it some years ago for biblioteca italiana project hacking the OCLC
oai server code).
There are a lot of possible solutions for this. I do not think this is
a definitive reason to call back to life independent headers.
Il 22/feb/2015 21:47 "Stuart A. Yeates" <[log in to unmask]> ha scritto:
> I have a use case for an independent header that I've never had time
> to implement (and likely will never get time to implement).
> There's a protocol in library land called OAI-PMH which is used for
> querying remote repositories for their contents. It's used by google
> scholar, for example to learn about the contents of issues of academic
> OAI-PMH is essentially parametrised by the format of metadata returned
> for each item. Variants of Dublin Core and MARCXML are common, but
> there's no reason why TEI XML couldn't be exposed alongside these.
> ...let us be heard from red core to black sky
> On Mon, Feb 23, 2015 at 7:03 AM, Lou Burnard
> <[log in to unmask]> wrote:
> > Hi Piotr
> > If you do a quick search through the archives, you will find that the
> > decision to abandon the "independent header" was quite deliberate, nothing
> > to do with conceit, and followed quite a bit of independent research. We
> > seem to be weak on institutional memory, so here's a brief summary of some
> > of the salient events.
> > In P4, there was a chapter which defined an "independent header". It defined
> > one element (<ihs>) which could be used (rather than <TEI.2>) as the root
> > element of an SGML dtd for documents containing only <teiHeader> elements.
> > It also contained some (lengthy) discussion of mapping between elements of
> > the header and other library standards, notably MARC.
> > Reviewing the components of P4, in April 2004, the Metalanguage workgroup
> > noted that the concept of "auxiliary DTD" is no longer relevant in the P5
> > architecture, and that specifically "The IHS is an artefact to enable a
> > valid document consisting only of headers, which could be accomplished in
> > other ways." [http://www.tei-c.org/Activities/Workgroups/META/mew07.xml] The
> > "other ways" they had in mind were presumably defining an appropriate ODD or
> > embedding TEI Header elements inside a document in another namespace.
> > The council meeting in July 2004
> > (http://www.tei-c.org/Activities/Council/Meetings/tcm12.xml) notes concerns
> > that the library-standards-mapping aspects of the old chapter should not be
> > lost, and that its material should be reworked either as a new chapter or
> > (as eventually happened) as a component of the existing header chapter. .
> > No-one seems to have argued for retaining an element like the old <ihs> in
> > P5, and no serious use case was proposed for it.
> > Two members of the Libraries SIG, who were also members of the Council, did
> > start work on a revision of the old chapter in a bid to bring its
> > recommendations on best practices for interoperability up to date and a
> > draft of this document was considered for inclusion in P5. However, at
> > the April 2007 Council meeting
> > (http://www.tei-c.org/Activities/Council/Meetings/tcm30.xml) where the
> > status of all P5 drafts chapters was reviewed, Council felt the work was
> > incomplete, probably out of scope for the Guidelines, and better handled by
> > the Libraries community. . Again, there is no record of any proposal for
> > a possible container element for a set of <teiHeader> elements.
> > In February and March 2013, there was a brief discussion of this "ghost"
> > chapter on the Council mailing list, which reiterates (most of) the history
> > I have summarised above, and re-affirms that the best way forward is to
> > incorporate recommendations from the Libraries community into the Header
> > chapter. Kevin Hawkins concluded this by observing [on 17/03/2013] "To
> > close the loop (you all know how much I like to do that), I now think it
> > would be better to leave this unfinished work as is and focus instead, as
> > we've previously discussed, on incorporating relevant portions of the Best
> > Practices for TEI in Libraries into the Guidelines."
> > Since that date, there have indeed been a few proposals for change to the
> > Header chapter addressing this need. But no-one till now has asked for
> > anything like the old <ihs> to be reinstated. As I said before, it is hard
> > to see what the use case for such an element would be, given the
> > availability of other mechanisms for doing the same job.
> >  "Noting the intention to remove the chapter on the Independent Header,
> > P[erry] W[illett] commented that members of the Libraries SIG attached
> > considerable importance to the material presently in that chapter about the
> > relationship between the TEI Header and other metadata schemes, which should
> > be maintained and updated. Council noted that there was a need for such
> > comparative information, whether or not the independent header module was
> > retained as a distinct schema. It was agreed that the editors should try to
> > draft a discussion of related issues which might become part of the header
> > chapter or a free standing document.
> > Action [by 1 sep 2004] editors: draft document discussing relationship
> > of TEI Header to other meta standards on the basis of material already
> > available, to be handed to the TEI Libraries SIG for improvement and
> > updating."
> >  The draft lingers on in the TEI source tree at
> > P5/Source/Defunct/SH-Other-Metadata-Standards.xml
> >  " M[atthew] D[riscoll] recommends chapter be dropped. J[ohn] W[alsh]
> > (co-author of the re-write) concurs. JW was assigned to draft a few
> > paragraphs discussing the relationship between the TEI Header and other
> > standards (including MARC and Dublin Core) in general terms, without
> > detailed mappings.
> > Action 52: JW TRAC http://tei.oucs.ox.ac.uk/trac/TEIP5/ticket/336 . Draft
> > paras on metadata standards 2007-05-05
> > Action 53: SB put JW paras in appropriate place at end of HD 2007-05-12 "
> > On 21/02/15 20:32, Piotr Bański wrote:
> >> Hi Peter,
> >> Thank you for the response! Well, the header I've just prepared has a <p>
> >> under <text> and <body>, which contains a single sentence with a single
> >> <ref> in it. Of course, this can be called, hmm, abuse of the intentions.
> >> But it's the intentions that I'm interested in. Independent headers used
> >> to be printed on many of the flags that the TEI once waved. Have we got so
> >> conceited as to burn them all? A lot of selling points gone in that smoke,
> >> it seems.
> >> Best regards,
> >> Piotr (rubbing his hands in anticipation...)
> >> On 21/02/15 21:05, Peter Stadler wrote:
> >>> Others will probably be able to tell you more on the historic shift from
> >>> P4 to P5 but to my knowledge a TEI P5 conformant document *must* contain "a
> >>> single teiHeader element followed by a single text element, in that order“
> >>> [1,2] (I’m skipping the teiCorpus stuff and note that we introduced
> >>> model.resourceLike which can replace <text>, but still, there has to come
> >>> something after <teiHeader>)
> >>> So, officially there are no independent headers any more, I’d say!?
> >>> Hope that helps
> >>> Peter
> >>>  http://www.tei-c.org/release/doc/tei-p5-doc/en/html/USE.html#CFAMmc
> >>>  http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-TEI.html
> >>>> Am 20.02.2015 um 12:02 schrieb Piotr Bański <[log in to unmask]>:
> >>>> Hi all,
> >>>> Are independent/free-standing TEI headers gone with P4?
> >>>> I can't find any mention on them, either in the P5 guidelines or in the
> >>>> wiki.
> >>>> I can find this, though:
> >>>> http://www.tei-c.org/Vault/P5/1.0.1/doc/tei-p4-doc/html/SH.html
> >>>> And a poster from TEI@20, by Michelle Dalmau and Melanie Schlosser,
> >>>> addressing among others "alternatives to the [independent header schema] in
> >>>> light of P5" (which might just indicate a change of the technology for
> >>>> maintaining said schema).
> >>>> I'll be grateful for any pointers and information.
> >>>> Best regards,
> >>>> Piotr