I note the following things in the definition for <correspAction> in the corresp ODD 1) you should not use @mode="add" together with @module on an <elementSpec> -- it's meaningless, since you are not allowed to add new things to existing TEI modules 2) if you want your valList to appear in the schema you must put @type="closed" on it. otherwise your suggested values appear in the schema only as comments 3) since you are replacing the existing (vacuous) declaration for the possible values of @type, you must put @mode="replace" on your valList With these changes, things work as expected for elements in the TEI namespace. I am still puzzling over why they don't for non-TEI namespaced elements, but have to go out now.
Bravo! Yes, it's the presence of @module that's the problem. Well caught. And it worked for me on the non-TEI namespaced <correspAction>. (But note that type="semi" is perfectly reasonable ... yes, the value list occurs in the schema "only" as comments, but a processor may read those comments and, e.g., make a pop-up list as oXygen does.) (And also note you don't need mode=replace on the <valList>, I suspect because it's not that att.typed has an empty <valList> you are replacing, but rather it doesn't have one.)
I note the following things in the definition for <correspAction> in the corresp ODD
1) you should not use @mode="add" together with @module on an <elementSpec> -- it's meaningless, since you are not allowed to add new things to existing TEI modules
2) if you want your valList to appear in the schema you must put @type="closed" on it. otherwise your suggested values appear in the schema only as comments
3) since you are replacing the existing (vacuous) declaration for the possible values of @type, you must put @mode="replace" on your valList
With these changes, things work as expected for elements in the TEI namespace. I am still puzzling over why they don't for non-TEI namespaced elements, but have to go out now.
Am 30.01.2015 um 16:55 schrieb Lou Burnard
: 1) you should not use @mode="add" together with @module on an <elementSpec> -- it's meaningless, since you are not allowed to add new things to existing TEI modules Hmm, is this a bug or a feature?
Some thoughts: * In an earlier version of the customization I added a module „correspondence“ and added all my classes and elements to this module. I think that’s a fair approach that should be supported. * we can delete elements from a TEI module, so why should we be not allowed to add stuff? Or is the „delete“ mode not really deletion but exclusion —> a quite sophisticated argument, though * since customizations can become sources of other customizations, what sense does it make to allow for deletions but not additions. (NB: a pure element subset of TEI_all does not guarantee a valid TEI file since I could delete e.g. teiHeader …) Anyway, thank you very much! I updated the proposal accordingly and it works like a charm :) Best Peter
participants (3)
-
Lou Burnard
-
Peter Stadler
-
Syd Bauman