OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [dita] Specialization of Attributes


Hi, Bruce, Eliot, and Paul:

Thanks for the thoughtful responses -- let me offer a different perspective.

On the point of sharing across communities of interest, a core part of the DITA approach consists of agreeing on a base definition that captures the common requirements of a broad community and creating a more precise subsets of that base definition for narrower communities.

Given that our content contains controlled values, how can we share content if we can't apply the same approach to the definition of controlled values? If I only care about operating systems to the level of Linux and you've defined operating systems down to the level of RedHat and SuSE, don't we need a way to share an agreed definition to the level of Linux, which you can then extend to RedHat and SuSE?

Regarding attribute specialization, I'd agree that we aren't taking a subset of a list of controlled values but rather identifying semantic relationships between differently enumerated properties. For a use case, imagine a process that searches the platform attribute for fuzzy matches on operating system names and creates an index of operating systems. If we can't express the specialization of an os attribute from a platform attribute, that process will miss the matches from the os attribute.

About conditional expressions after generalizing a specialized enumeration -- my understanding of the proposal is that the specialized enumeration would be addressable in the generalized form. In other words,

....<prop att="os" val="linux" action="exclude" />

would match either

....<note os="linux">Be sure to ...</note>

or

....<note platform="os(linux)">Be sure to ...</note>

The problem with Boolean logic embedded in content is that those expressions are very easy to get wrong and tend to be specific to a purpose. By contrast, if we make simple semantic assertions about the content ("this note is about Linux"), we can support filtering, indexing, styling, inferred linking, and any other operation based on what the content is about.

Inline enumerations have their limitations, but I don't think we want to force people directly to something external like the Taxonomy specialization. (Given that there's no method currently for filtering based on externally defined subjects, that's not even an option now.) People who only want to define a schema or document type should be able to have extension for metadata. That is, DITA should support the range of users.


Hoping that's interesting,


Erik Hennum
ehennum@us.ibm.com



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]