If you understand what's happening, then there are measures you can take
in Oxygen to prevent (for instance) expansion of default attribute
values during XSLT transforms. There's doesn't seem to be a comparable
option for XML diffing; it would require that the diff process be
schema-aware, which perhaps it isn't.
But the fact that TEI folks with many years of experience and some
significant level of skill are still tripped up by this suggests that
it's not a healthy situation; we really don't want what amount to unseen
magical assertions being made about users' data without their knowledge.
On 2016-08-26 11:45 AM, Sewell, David R. (drs2n) wrote:
> Speaking to the general question about default attribute values, I have
> always found them to be more of a nuisance than a help, in large part
> because they interfere with the task of comparing XML files that are
> identical but for the presence or absence of attributes with a defined
> default value.
> I.e., if I am using a diff tool like oXygen's to compare two TEI files,
> where one has "<note anchored='true'>" everywhere and the other has just
> "<note">, the two elements will be reported as different. This has
> caused me to spend more time than I'd like checking to find substantive
> differences between files created at different times or via different
> But as I think about and look into it, I'm not sure why oXygen doesn't
> provide an option to consider default attribute values when diffing XML
> files, unless it's that the diff tool does not take schemas into
> account. oXygen does provide the ability to expand or not expand default
> attribute values during an XSLT transform (because its underlying Saxon
> engine supports that).
> Should one expect that an XML diff tool would take default attribute
> values into account? Would it be an appropriate feature request for
> oXygen, or are there implementation problems that I'm ignorant of?
> On Fri, 26 Aug 2016, Martin Holmes wrote:
>> Hi all,
>> Many TEI users are not aware of it, but there are many attributes in
>> the TEI universe which are defined as having default values; this
>> means that whether or not you know the attribute exists, you are
>> notionally using it with a value that has been specified as a default.
>> An example is the @defective attribute, which appears on a number of
>> elements including <quote>:
>> The default assertion made by this attribute in the context of <quote>
>> is that the quotation is not "defective". This means that even if you
>> don't know anything about the attribute, if you have it included in
>> your schema (or you're using tei_all or another schema which includes
>> att.msExcerpt), you are unconsciously making the assertion that all
>> your <quote>s are @defective="false". As I've noted on this ticket:
>> 'This means that every time you use a <quote>, even if you explicitly
>> remove part of it and insert an ellipsis, you are asserting without
>> your knowledge that the quote is not "defective". This is wrong.'
>> Along with several Council members, I'm not keen on the notion of
>> default values for attributes. They cause two specific problems:
>> - They have the effect that many users are implicitly making
>> assertions about their data that may not be correct, without their
>> knowledge; and
>> - they lead to unexpected and confusing results during XSLT
>> transforms, when they may suddenly appear in the output -- see, for
>> example, these two threads on TEI-L:
>> I believe that the default attribute value mechanism, although useful
>> in the era of the DTD, is more appropriate now in the context of
>> project-specific ODDs, and should be much less prevalent in the
>> standard TEI schemas.
>> As a result of this, Syd and I have been working on a number of
>> tickets that aim to reduce the number of default values for attributes
>> in the schema. One of them is 1457:
>> What we would specifically like to know is this:
>> Is there anyone on this list who is not only aware of the default
>> value for the @defective attribute, but who actually depends on its
>> defaultVal in their project? In other words, if we remove the default
>> value (meaning that we remove its defaultness, not the value itself,
>> which would still be available), would your project be impacted at all?
>> Any other comments on the <defaultVal> mechanism would be very welcome