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: Specialization support: a core philosophical issue



Per today's TC meeting, summing up my thoughts on required support for the core spec (new minimal architectural spec plus core language spec) vs for specialization specs (new separate docs for tech content, machine industries, etc.) vs for user specializations.

Core spec:
- all DITA implementers need to support the core specification and provide its documented behaviors as defaults
- we need at least three documented users for the core spec, per OASIS requirements

Standardized specializations:
- some DITA implementers may also choose to support the extended specifications for standardized specializations and provide their documented behaviors as defaults, including cases where the specialized behaviors override the core defaults
- we need at least three documented users for each standardized specialization, or it shouldn't be considered "baked" enough to become part of the standard

User specializations outside the standard:
- where a particular user or community creates additional specializations beyond those in the standard, they can expect default support based on inheritance (from either the core, or from a standardized specialization if appropriate)
- but if they want behaviors that override what they get by default, they will need to provide those overrides themselves
- this is pretty much the same as if the user went with a vendor that didn't support the standardized specialization they needed (ie they'll get inherited behavior, but not specialized behavior, unless they develop it or someone develops it for them)

Sum:
- everyone needs to support the core;
- specialized support (beyond core defaults) for the specialized parts of the spec are optional but encouraged, and should represent an established user community;
- specialized support (beyond core defaults or standard specialization defaults) for non-standardized user specializations are up to the user or their partners to provide

Philosophical point:
- specialization doesn't eliminate differences between markup languages (although it does reduce them), it provides a framework for managing those differences

Michael Priestley
Lead IBM DITA Architect
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25


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