Hi George and Gioele,
After half a year, I found some time to continue working on this approach.
To recap, the approach is to use the schema of an unaltered default
customization, for example tei_allPlus.rng, together with another RNG
schema that will allow almost anything everywhere, except for certain
elements such as div and floatingText. This second schema provides a
grammar that specifies in which order and cardinality these typed
elements may appear and how they may be nested.
The remaining problem that we discussed was about how oXygen’s
context-aware editing aids can make use of the combined rules. When
associating these schemas with two xml-model instructions, only the
schema of the first xml-model will be used for element name suggestions.
So you can choose to have the plain TEI rules with no type restriction,
or a very sparse list that suggests that you can only insert divs and a
few other elements.
Combining both schemas in NVDL
improves the situation. The elements that oXygen now offers seem to be
the union of the elements that each schema allows in a given context.
Since the second schema needs to explicitly model each element that is
allowed to contain typed divs and floatingTexts, the 'anything' define
of the second schema contains references to some concrete elements,
namely div, floatingText, front, body, and back. These few elements now
also, and often falsely, appear in oXygen’s list of permitted elements.
When the user enters these, they will immediately be flagged as
validation errors though.
This is a slight drawback of the NVDL approach. The approach comes,
however, with a nice benefit, and that is the context- and grammar-aware
lists of permitted type attribute values for div and floatingText. So I
assert that it’s useful and arguably more adequate than shoehorning
grammatical rules into Schematron.
You can open this URL in oXygen to see a sample document and play around
with its div & floatingText nesting rules:
On 24.06.2016 18:31, Imsieke, Gerrit, le-tex wrote:
> Hi George,
> This is not equivalent. The combined schema that you suggested allows
> you to construct documents that are not valid TEI.
> For example, it allows this as body content:
> <div absolute="s" type="chapter"></div>
> which is invalid wrt the TEI schema. The combined schema seems to allow
> the union of what any of the two schemas would allow at a given point.
> However, the purpose of the extra schema is to further constrain what
> the basis schema allows, not to extend it.
> I’d like to know whether there is another way to specify these extra
> constraints in an adornment schema that may be combined with the
> original schema.
> On 24.06.2016 11:21, George Bina wrote:
>> What about using a schema that combines the two schemas, like
>> Note that you need to disable the ID/IDREF checking from
>> Options->Preferences -- XML / XML Parser / RELAX NG because there are
>> conflicting IDs defined.
>> Best Regards,
>> George Cristian Bina
>> <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
>> On 24/06/16 02:30, Imsieke, Gerrit, le-tex wrote:
>>> Hi Gioele,
>>> Neither an ODD nor a Schematron approach: You can use a second RNG
>>> schema. Here is a sample schema (that also serves as a blog post about
>>> this approach):
>>> I tried to prescribe div/@type attributes in such a way that the types
>>> correspond to DocBook element names, and the grammar is (roughly) the
>>> same as in DocBook. So you have parts or chapters in the body, prefaces
>>> and dedications in the frontmatter, etc.
>>> The nice thing is that you superimpose a bespoke grammar on an
>>> off-the-shelf TEI schema. An actual grammar refining an unaltered base
>>> schema, if that doesn’t sound compelling. You can’t do this with
>>> Schematron so handily.
>>> A sample document is here:
>>> If you open it in oXygen and add a type attribute to body/div, you will
>>> be presented with a choice of part and chapter.
>>> This is the good news.
>>> The bad news is that there will be no other completion hints than those
>>> from the epischema – unless you swap the xml-model PIs at the top, but
>>> then you’ll only have the default TEI vocabulary as suggestions.
>>> Maybe we can convince the oXygen people to restrict the autocomplete
>>> options to the intersection of the choices that all referenced schemas
>>> offer at a given location.
>>> On 22.06.2016 18:14, Gioele Barabucci wrote:
>>>> in ODD, how can I change the constraints of the <div> elements that
>>>> appear in a certain position (e.g., /TEI/text/body) while using the
>>>> default definition for all the other elements?
>>>> I could specify those constraints as a set of Schematron assertions,
>>>> those would not be picked up by, for example, oXygen for the automatic
>>>> completion of element names and attribute values.
>>>> In RelaxNG one can give two different definitions of <div>: one for
>>>> those elements appearing in a certain production, and another for all
>>>> the others contexts. Can the same thing be done in ODD?
>>>> The use case for this request is that I would like <div>s in
>>>> /TEI/text/body to contain only few whitelisted elements, while allowing
>>>> <div> in other places (mainly the header) to be unconstrained.
>>>> Note: Element names and element definitions are separate entities in
>>>> RelaxNG; in ODD it looks like element names and their definitions
>>>> be separated (I suppose this has to do with DTD support). Probably this
>>>> means that what I am looking for cannot be done, but I think it is
>>>> asking anyway.
Geschäftsführer / Managing Director
le-tex publishing services GmbH
Weissenfelser Str. 84, 04229 Leipzig, Germany
Phone +49 341 355356 110, Fax +49 341 355356 510
[log in to unmask], http://www.le-tex.de
Registergericht / Commercial Register: Amtsgericht Leipzig
Registernummer / Registration Number: HRB 24930
Geschäftsführer: Gerrit Imsieke, Svea Jelonek,
Thomas Schmidt, Dr. Reinhard Vöckler