Re: [xml-dev] A generic approach to XML design versus a hardcodedapproac

The DITA standard enables both.

DITA's specialization mechanism allows you to define "hardcoded" elements that directly reflect the desired semantic and of course also enable normal grammar constraint using normal element content rules (that is, no need for a supplementary Schematron, not that there's anything wrong with that).

In addition, all DITA elements take the "@outputclass" attribute, which is intended to reflect an author-supplied hint as to how to further interpret the element, whether it's for a specific rendition target (e.g., outputclass="font-weight: bold; color: red;") or as a way to capture unconstrained semantics (<p outputclass="myspecial-para">).

The generic metadata container <data> uses a @name attribute to define the "field name" of the metadata item, so you can do:

When you specialize the <data> attribute you can set the @name attribute to a default value so processors can reliably look for @name, e.g.,:

<dc-title value="Title of Something"/> where name="dc-title" is set as a default in the governing grammar.

Likewise, the generic <note> element takes a @type attribute, which if it has the value "other" requires that you set the @othertype attribute to whatever value you want to use.

The secret sauce in DITA is the @class attribute, which specifies the specialization hierarchy of an element, allowing processors to apply more-general processing to elements they don't recognize directly, e.g.:

<my-para class="+ topic/p mystuff/my-para "/>

Per the spec the @class value is supposed to reflect the local tag name in the last token but nothing really enforces that, so you could do:

And DITA processors would know that this paragraph can also be treated as a mystuff my-para. But you would not expect authors to do this under normal circumstances. But it is another example of being able to use attributes to associate more-specific semantics with less-specific element types.

One issue with using attributes to associate additional semantics of course is that normal XML grammar mechanisms don't allow you to constrain them or use them to control content models.

Cheers,

Eliot

Eliot Kimber

http://contrext.com

From: "Costello, Roger L." <costello@mitre.org>
Date: Friday, October 7, 2016 at 8:20 PM
To: "xml-dev@lists.xml.org" <xml-dev@lists.xml.org>
Subject: [xml-dev] A generic approach to XML design versus a hardcoded approach to XML design

Hi Folks,

Compare these two designs for modeling an event occurring on March 21, 2012:

The second design uses a “generic approach to XML design.” The <event> element denotes any arbitrary (generic) event. The attribute value identifies the specific event.

The first design uses a “hardcoded approach to XML design.” The <graduation> element hardcodes the event.

In the generic approach the semantics is in the attribute value. In the hardcoded approach the semantics is in the element name.

The generic approach, when coupled with Schematron, enables the creation of powerful (flexible, extensible) data models. Other events can be readily created without any modification to an XML Schema. For example:

Here’s another event (note the rich semantics):

Regrettably, many people are not taking advantage of generic XML designs. Here’s what Rick Jelliffe says:

Mainstream XML technology definitely disfavors generic approaches:
               to move to generic approaches where the specific semantics is in
               attributes *and* retaining validation requires moving to RELAX NG
               or Schematron in which attributes are first-class citizens (rather than
               DTDs or XSD where all patterns/types are keyed by element context
               only.)

Comments?

Thanks Rick for raising this important issue.

/Roger