#661 outdated schematron constraint 'msId_minimal'?!


To me the schematron constraint 'msId_minimal' at <msIdentifier> seems outdated in at least two ways:

  • I believe it's perfectly valid to only have <altIdentifier>s as children of <msIdentifier> (use case: one logical object, scattered across several institutions. Cf. http://tei-l.970651.n3.nabble.com/multiple-msIdentifiers-tp2416599p2416117.html)
  • since several child elements of <msIdentifier> could simply be pointers (e.g. <repository ref="my:repo"/>) the check for empty text will falsely fail

I'm not sure whether this rule is needed anyway but if so it should be updated.

The current constraint for convenience:

    <report xmlns="http://purl.oclc.org/dsdl/schematron" test="not(parent::tei:msPart) and (local-name(*[1])='idno' or local-name(*[1])='altIdentifier' or normalize-space(.)='')">An msIdentifier must contain either a repository or location of some type, or a manuscript name</report>


  • James Cummings

    James Cummings - 2014-04-15

    If I understand this correctly the schematron rule is trying to enforce the idea that an msDesc/msIdentifier needs to have some location, repository, or identification (whereas an msPart/msIdentifier has no such restriction). I think we took this to be the minimal required information about a manuscript or set of manuscript bits.

    In the example of the given of a logical object scattered in different institutions the msDesc/msIdentifier is identifying the logical object of which you speak. When you speak of it, doesn't it have an identifier or msName of some sort? If you can't talk about the object as a virtually or once-combined object then it seems strange to have a description about it. The post linked to is now wrong (in that you can't just have altIdentifier any more it seems) but you just need one country or similar element, or repository or idno or msName or similar. I believe the argument is that you almost always have an idno or msName. If you are virtually reconstructing this ms from pieces scattered in different countries, then surely the idno or msName is the name or idno that you give to identify this collected ms? The individual idno's for each scrap go inside their msPart obviously.

    The check for empty text is a fairly limited one (trying to stop people just putting in contentless elements. But I suppose could check for a @ref as well. I think it a good idea to test for where someone has put a repository but no text in it. (I'd still be tempted to suggest your repository example should have a human-readable blob of text in it....)

    Just thinking out loud,


  • Peter Stadler

    Peter Stadler - 2014-04-15
    1. the schematron rule does not allow idno nor altIdentifier as a first child of msIdentifier, hence prohibiting the sole use of idno or altIdentifier+ within msIdentifier
    2. I do not think you necessarily need a name (or similar identifier) for speaking about (better: referring to) a source of an edition/text. In my projects e.g. we are dealing with letters which do not have such kind of a name. But, there are cases where manuscripts were cut apart and given away, resulting today in different repositories for these fragments.
  • James Cummings

    James Cummings - 2014-04-15
    1. It doesn't? It seemed to stop warning me about it when I put <idno>foo</idno> in there. But yes, doesn't work for altIdentifier+ (and I'm fairly agnostic about that to be honest... I was just rehearsing what I believe the argument was for status quo).
    2. Fair enough, I think I'm convinced by that and think we could allow altIdentifier+ as only content of msIdentifier. I'm still thinking that we should require that at least one of these elements inside msIdentifier should have text content of some sort...
  • James Cummings

    James Cummings - 2014-05-19
    • assigned_to: Peter Stadler
  • James Cummings

    James Cummings - 2014-05-19

    Assign to Peter Stadler to report on issue to council and encourage them to provide an opinion here, and shepherd this ticket through to some conclusion.

  • Hugh A. Cayless

    Hugh A. Cayless - 2014-06-30
  • Hugh A. Cayless

    Hugh A. Cayless - 2014-06-30
    • status: open --> closed-duplicate

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks