This is a great summary of the issue, representing exactly how I feel,
and expressing it much more clearly than I did. :-)
It is possible for CSS to insert content in the rendering of a document,
using e.g. the ::before and ::after pseudo-elements and the content
property. But that's not the same as injecting it into the HTML or XML
that's being styled.
On 2020-01-16 9:01 a.m., Kampkaspar, Dario wrote:
> Dear Peter, Martin and list,
> (Peter Flynn wrote:)
> > I'm not familiar with the scenario where part of the document content
> resides inside the DTD (with the exception of default attribute values).?
> In my mind this is actually a big point. Defaults are the only case
> where something might be added automatically to the (result) tree
> without being actually part of the input tree or transformation. This
> along makes me wonder whether it is really a good thing. A mandatory
> element, e.g., would not be added to the tree (the element defaulting
> mechanism in XML Schema can only add default content to a void element
> and only if it has been specified).
> Defaults mean that some part of the document is not part of the original
> tree returned by the XML parser (as they only come to life after
> validation): it is incomplete up until the point of validation; if I do
> anything with the document before validation, I do not have the complete
> tree. Especially, as XSLT processors do not have to be schema aware, it
> is well possible that no validation takes place before processing –
> which means that part of the information in your intended tree may be
> lost depending on the tool you use!
> Furthermore, default attributes can change the meaning of a text, just
> consider <foreign>boot</foreign> e.g. somewhere in the teiHeader –
> originally written by a British person. Then someone sets the default
> for @xml:lang to be "en-us", because all the texts in the project are
> from the US. This changes not the meaning of the foreign element, but
> completely changes the meaning of what has been encoded.
> The thing we all like about our XML universe is the separation of
> concerns. We separate style from content, the structure is defined in a
> different file from where it is used. The ODD serves to describe the
> meaning of the structural markup, just as the semantics e.g. of HTML are
> not inherent to any kind of schema file but actually arise from the
> prose of the standard.
> Changing the CSS does not change the structure or meaning of the text in
> the XML file; while changing the prose definition of <p> in the ODD
> changes what we say _about_ that stretch of text, it does not alter the
> meaning of that stretch of text. Even (more or less controversial)
> processing instructions, even though in a way breaking this separation,
> don't change the meaning of the text that is encoded. The example above
> shows that default attribute values can do just that.
> After these considerations, I strongly agree with Martin that default
> attribute values are rather problematic (and have not been made part of
> Relax NG for a reason, see https://relaxng.org/jclark/design.html s.v.
> “Attributes”). I dislike both the fact that they can change the meaning
> of the text in and also that by standard the mean that the tree we're
> talking about is actually implementation-dependent. Both are, to my
> mind, actually strong violations of the basic principles of “separation
> of concerns” and “meaning is independent of implementation”.
> All best,
> *Von:* TEI (Text Encoding Initiative) public discussion list
> <[log in to unmask]> im Auftrag von Peter Flynn
> <[log in to unmask]>
> *Gesendet:* Dienstag, 7. Januar 2020 21:40
> *An:* [log in to unmask]
> *Betreff:* Re: Specifying a default language for elements
> On 07/01/2020 00:54, Martin Holmes wrote:
>> Hi Michael,
>> One of the things I dislike about the DTD system is the way the document
>> and its schema are woven together, so that the document is not complete
>> without its schema.
> I'm not clear how this is not the same with other schema systems (W3C,
> RNG). Excluding schemaless documents, this is always true AFAIK.
>> I understand how that situation arose, but it's a bit pernicious;
>> altering a schema may alter a whole set of documents without actually
>> touching them (or possibly even knowing they'll be altered),
> But this is true of all schema systems, surely,
>> and the now-common practice of using multiple schemas on the same
>> document collection for different purposes
> I must be living in a different time-line :-) Yes, it's possible; no, I
> wouldn't recommend it. Perhaps this has become commonplace in the TEI
> arena since I left.
>> becomes very awkward if some of the actual content of the documents
>> is not in them, but is in a different schema.
> I'm not familiar with the scenario where part of the document content
> resides inside the DTD (with the exception of default attribute
> values).?Do you have some examples/
>>>> In addition, there's the issue that you then end up requiring
>>>> different schemas for different documents in the same
>>>> collection, because they need different values for @xml:lang on
>>>> specific elements.
> This smacks of insufficient document analysis before design. But there
> are ways of switching such alternatives in and out which are very simple
> to implement.
UVic Humanities Computing and Media Centre