Re: [dita] Simplifying specialization rules - the state of the discourse

Graydon Saunders | Lead Developer | Precision Content
Direct: (637) 557-4995 | Email: graydon@precisioncontent.com | www.precisioncontent.com

Unlock the Knowledge in Your Enterpriseâ

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. Please notify us by return email if you have received this email in error. Â2020, Precision Content Authoring Solutions Inc, Toronto, Ontario, Canada

I've been working off and on on Issue 15 - Simplifying content model specialization rules. The goals of this proposal are relatively straightforward and broadly agreed upon:

- You should be able to add elements to individual content models without making them globally available on every element - e.g. add <section-shortdesc>, a specialization of <p>, only within <section>, not everywhere <p> is allowed.

- You should be able to add attributes to individual elements without making them globally available on every element - e.g. add @cell-purpose as a specialization of @base, but only on <entry> and <stentry>.

The word I've been playing with is "mix-in." When you want to add an element or an attribute to a specific element, you create a mix-in for that element.

1. Define a domain that defines the elements you want to add, but don't create the "domain integration" entities as you normally would.

2. Define a "mix-in" module for the content model(s) and/or attribute list(s) you want to add your element(s) and/or attribute(s) to.

3. Link both your domain and your mix-in into your doctype shell.

In implementation, a mix-in is identical to a constraint, except that instead of removing elements from the content model, you're adding them. People have varying degrees of frustration with the word "mix-in" and I'm wide open to suggestions, but it's the best I've been able to come up with so far.

Kris, Robert, Eliot and I have had a few conversations around this, and while we all agree with the goals, and broadly agree on the mechanics of how we'd implement it, we're at a bit of an impasse for how we frame these things in the spec language.

The problem is the relationship between mix-ins and constraints. Initially I had no intention of explicitly linking them, but as I wrote the Stage 3 proposal I hit a linguistic snag.

For various boring technical reasons I won't get into here, if you have two constraints that apply to the same content model or attribute list, you have to combine them into a single constraint module. The same is true if you want to apply multiple mix-ins to the same element; you have to combine them. And it's also true if you want to apply both a mix-in and a constraint to the same element. You have to combine them into one thing.

What do we call that one thing?

I came to think that mix-ins and constraints are two sides of the same coin, not just in terms of their implementation details, but also conceptually. They are both modifications of a specific element's content model and/or attribute list. So I coined the term "content model specialization" (again, open to suggestions, I don't love it but couldn't come up with anything better) and started referring to constraints and mix-ins as kinds of content model specialization. And when you need to combine a mix-in and a constraint, you create a new content model specialization that does both.

It's not a perfect solution. Constraints can do more than just affect a single element - you can globally constrain out whole elements from domains, for example. But it's the best I've been able to come up with to solve this linguistic conundrum.

Some of the disagreement is over the phrase "content model specialization," and again, somebody, please come up with something better. But I think some also feel very strongly that constraints and mix-ins need to be treated as entirely separate concepts in the spec, and object to the umbrella 'content model specialization' terminology. I just don't know how else to answer that question above - 'what do we call that one thing?' And I have come to think of them as variations on the same concept - modifying a specific element in some way.

So that's where things stand on Issue 15. Others, feel free to chime in with additional details or context or correction. I look forward to discussing it with the committee on Tuesday.

Chris

dita message