On 25/08/11 17:15, Espen S. Ore wrote:
> Some of the problems perceived by Henrik Ibsen's Writings are not that
> there are too few elements (although we have invented a small amount)
> but that the content models do not fit the way we are modeling our
> texts. And this is where we may have thought wrongly: we have decided
> as part of our upgrade to P5 that if we change an element's content
> model apart from attributes, then we define a new element in our own
> namespace to keep clear what is unchanged TEI and what is not. So in
> our texts in addition to the standard TEI P5 elements we have new
> elements: <HIS:printer> and edited versions of TEI-elements such as
> <HIS:hisAdd>, the last one an extension of the tei <add> element. And
> so on.
> But should I now read the discussion here as meaning that we should
> rather have edited the TEI-elements and kept them in the TEI namespace?
No, I think not. Or at least, it depends on whether the modification to
the content model is a "clean" modification.
Certainly the current policy is that you MAY change the definition of a
TEI element or attribute ONLY so long as the new definition remains
compatible with the definition in TEI-all. In other words, if a certain
attribute value is valid according to your schema, then it must be valid
in TEI-all. If an element may have a certain child in your schema, then
that child must also be valid in TEI all. If you follow this rule, then
any document which conforms to your schema will also be guaranteed to
conform to the TEI-all uber-schema.
On the contrary, if you wish to make incompatible ("unclean") changes,
then you must not re-use the qualified name of a TEI element - you must
define a new element in another namespace. Note that the "local name" of
your element may be the same as the "local name" of a TEI element; if
the namespaces are different then the elements have different qualified
names. So you may certainly define an element called <his:add> and not
worry that it conflicts with the <tei:add> element.
> We are prepared to handle over both our encoded texts, our schema and
> our ODD-file for that matter, and also the Roma-generated
> documentation of our schema. But we have not planned for - meaning we
> have no money or person-time - work to define a way to emasculate our
> text files to an 80% version in pure TEI. So we obviously have other
> priorities, Does this mean that we are not one of the respectable
> projects? However that may be, Henrik Ibsen will be published on the
> web on Sept. 17 this year.
NB such an XSLT is not necessarily a difficult thing to write -
extremely easy if you aren't too worried about information loss.
e.g. here's one which simply discards everything in a namespace with the
prefix "his" (I don't know your namespace URI), except that it converts
his:hisAdd elements to tei:add elements.
<!-- copy any element -->
<!-- copy any attribute -->
<!-- but ignore any elements or attributes in the "his" namespace -->
<!-- except convert his:hisAdd to tei:add, copying any xml:id attribute
but ignoring any other attributes -->
eResearch Business Analyst
Victorian eResearch Strategic Initiative