The Oxygen forms editor uses the schema information to select which framework to apply. Epidoc is a TEI schema, so Oxygen tends to apply the TEI framework. In addition, it's not possible to differentiate between different epidoc implementations, which may require different templates for entering an inscription.
I propose that we suggest adding an ID of some type on the root element, so that different types of processing can take place. This might identify the collection that the inscription is coming from (USEP). Unfortunately, Oxygen only takes into account attributes on the root element. probably because it's the only element that will reliably be there without reading the schema?
This is more of a suggestion than anything else. Lessons learned.
Need to report back with more details for next spring
In Oxygen the following features are used to identify a document type and associate it with a document. This is what brings in the appropriate CSS for Author mode, also potentially the schema and any transformations or actions needed when encoding a document.
Of all the options "Attribute" seems to be the simplest. Another option, according to a response from Oxygen, is just to turn off the irrelevant frameworks in the pref. pane, or to perhaps set the priority so default TEI is lower than Epidoc.
Discuss.
Last edit: Elli Mylonas 2014-06-25
That's true that the use of an attribute is the simpliest way of having a set of file automatically displayed in the Oxygen author tab with a given css or set of css files (because Epidoc is TEI, you can't discriminate them with root local name for example).
I tried it using the attribute <att>n</att> on the <gi>TEI</gi> element.
For a extensive use of css files for the author mode (which can provide entry forms), I would nevertheless recommand using projects, frameworks or addons.
To use a project in that aim, you have create a folder, put a projet file (.xpr) in it and then set the "associate type definition" (which contains the info on the css, schema and xsl transformation scenarios) at the project level. All the files of your project will use the properties of the associate type definition. Even as simple as it seems, it may be perceived as "too complicated" for certain users. In that case I would use an attribute as Elli proposes. But I may not want to add a specific attribute (and by that make a big difference between TEI and Epidoc), I would just use <att>n</aat>.
I agree that creating a non-TEI element (
@type
) is a bad idea.@n
seems not to be abusive to me.Elli, did you have any further thoughts?
This needs more thought. Not ready to take a stand yet, and there are other ways to handle the problem. Deferred.