[bug] schema modifications reflect unexpanded schema changes on expanded schema

[duncdrum]

The only currently actively maintained schema is the set of files called tei-betamasaheft.* in the schema collection. The expanded schema tei-betamasaheft-expanded.* intended for use on the expanded files has drifted out of sync. tei-betamasaheft-cdcc.* does not seem to be in active use.

Ultimately we will need to come to a shared human-machine understanding of what constitutes a valid file as a basis for the tei-publisher app, and how to implement it at each step of the publishing pipeline.

This involves:

• deciding on a fix for external files which are used by the application code, but who do not use the projects schema. Should these be transformed via xquery to be compatible, have their own custom schema, be displayed as is, added as an alternative encoding to the current schema … ?
• deciding on a fix to projects files which fail to validate, is the schema at fault here or the data ?
• resource allocation
• overall design, do we want to have one big master schema, a schema assembled from sub-schemas, multiple schemata for different repos, etc ?
• should we synchronise updates from the tei guidelines (v4) into the current schema (tei v3`), how to deal with this going forward.

We have multiple options in either directions. So this is largely a question to the current project members of what they would like us to work on, and what they consider to be the best approach in line with their goals.

[eu-genia]

• external files: this depends on the files: --IHA: I think the easiest would be to add alternative (deprecated) encoding (I still have some reservations, as some users may by chance then use this deprecated encoding and the files will still be valid, but I think since we oversee all external PRs we can have a certain control here). I can do it - can you show me the best way to highlight the deprecated elements? --other files: depends, I would say if they are not delivered with their own custom schema then be displayed as is, we have no capacity to do anything else about that
• failure to validate: -- as a rule, the data is at fault. we shall be trying to fix the data in the coming weeks/months, but it may take quite a while, since validation errors are different -- important: we have run the testing for well-formed XML in Oxygen and have not discovered any errors.
• resource allocation: what do you mean exactly?
• schema: while I do see the advantages of sub-schemata, I think this is not realistically feasible for us to have this change implemented. This would mean too many changes and too much work, also on the live app. So I am still for staying with one master schema. But we definitely need a synced schema for expanded files. if you can help us in getting there this would be appreciated!
• tei-guidelines: does this involve much change/work?

[eu-genia]

I have now updated the expanded schema (tei-betamasaheft-expanded) to reflect the changes carried out in the unexpanded one, and set all lists to open, so that it should validate more or less anything ) I have tried it out on the expanded files, which do not have validation errors, but get the error message probably the issue with the link <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="xmldb:exist:///db/apps/lists/canonicaltaxonomy.xml"><xi:fallback><p>Definitions of prefixes used.</p></xi:fallback></xi:include> ?

[duncdrum]

Yes I suspect so, modifying the syntax of the xincludes is something we'll need to look into soon.