RE: [dita] Re: Filtering logic for <enumerationdef> element

[Erik Hennum <ehennum@us.ibm.com>]

Hi, Jonatan:

Thanks for giving the scheme such close attention. Before responding to some specifics,
I'd suggest taking a look at the big picture.

The approved Scheme capability includes the following:

* Definition of a list or hierarchy of controlled values for a category
* Optional properties for a controlled value (such a readable title or definition)
* Optional binding of controlled values to attribute values via DITA keys
* Optional classification by reference in a map.

This thread suggests that the Scheme capability might benefit from enhancement in the
following areas:

* Integration with topic prolog metadata elements

* Direct integration with filtering logic (DITA values files)

Note, however, that none of the approved Scheme capabilities conflict with future
enhancement in these areas. For instance, any solution that defines controlled values
for the prolog metadata elements will need to define an enumeration of values for a
category and will benefit from integration with the selection attributes.

As a standard practice in many disciplines, it's best to roll out an increment and then
use the knowledge gained through the first phase for follow-on activity. For that reason,
I'd suggest the standard practice would be to follow through on the approved design
and defer discussion of expanding the solution until the requirements gathering period
for DITA 1.2

More specific responses below....


Hoping that clarifies,


Erik Hennum
ehennum AT us DOT ibm DOT com


"Jonatan Lundin" <Jonatan.Lundin@citec.com> wrote on 01/08/2010 04:08:36 PM:

> ...  I welcome the feature, since it really
> allows users (designers as well as writers) to manage metadata in a
> controlled fashion.
> ...
> 1)
> ... The subject
> scheme could include a markup model, when multiple <subjectdef>
> categories are defined within the <enumeratationdef> section, to
> allow designers of subject scheme taxonomies specify
> * that values from multiple categories, that are possible to a
> single attribute, can be made related using boolean expressions (and
> then which expressions)
> * that only one (1) value from one of the multiple defined
> <subjectdef> categories can be picked.

The approved proposal had a mechanism for binding multiple categories to a single
attribute. The decision to defer that feature makes good sense because, really,
the feature makes sense only as part of a more general direct integration of
scheme definitions with filtering logic.

Put it this way: technically, filtering processors _could_ consider the scheme as
well as attributes in determining categories. As Su-Laine pointed out, however,
putting multiple categories in a single attribute could be confusing to users. The
tradeoff is whether users have such a strong need to add new categories without
modifying XML Schemas or DTDs that some would want and be successful with
the feature.

That clearly requires a lot more discussion and would benefit from experience with
schemes in the wild. In other words, it benefits from deferring to DITA 1.3

Regarding putting boolean expressions in the scheme, DITA so far has followed the
facet logic model (unions within categories, intersections across categories). Adding
explicit boolean expressions increases the complexity as well as power (risking
inadvertent null sets, for instance). Again, consideration would have to wait to DITA 1.3

> 2)
> ... The subject scheme feature includes the ability to categorize a
> topicref to a subject in the scheme using the topicsubject and
> subjectref constructs. Here I'm afraid that users will end up with
> conflicting statements; the metadata in the topic prolog does not
> correlate to the referenced subjects in the map....

It's already possible for metadata attributes to assert something different than prolog
elements. That might actually be what the writer wants. A task about SQL SELECT
might be an expert topic in some contexts and a beginner topic in other contexts.

The benefit of classifying by reference is that you can classify in a new category without
having to modify DTDs or XML Schemas to add an attribute for the category. As noted
above, however, you won't be able to filter against the category with DITA 1.2
implementations of filtering logic.

>  
> 3)
> .... But what
> if a subject category, defined as holding the default value, is
> referenced that is not one of the subject category(ies) that is
> defined to hold the possible attribute values? The writer will be
> confused when the attribute has a default value not possible to
> select in the pick list?

Note that binding a category to an attribute is optional, not required. It would be pretty
limiting if the scheme were restricted _only_ to attribute bindings.

If a superuser / administrator decides to bind a category in the scheme to an attribute,
that user has the responsibility to define keys for the subjects. While a tool could
reasonably warn the user if some subjects don't have keys, that isn't necessarily
an error. The user could reasonably want to expose only the high-frequency subset of
the available controlled values via attribute bindings.