Re: [dita-s1000d-discuss] DITA specialization mechanism, revisited

[Scott Hudson <scott.hudson@flatironssolutions.com>]

Hi Joel,

again, thank you for your great comments on this topic!

You mention:

"One way to facilitate interoperability between S1000D and DITA is to use
S1000D element names and semantics when creating DITA specializations for
domains such as the machine industry."

I whole-heartedly agree. In fact, this is why we are trying to establish 
either a DITA SC or an OASIS TC to address the creation of such a 
specialization of S1000D in DITA.

The question is, should it be a DITA SC, or should there be a full TC 
established to address interoperability between the standards? I think 
you have given several of examples where a specialization would be 
beneficial. Now the question is how to go about creating it.

Best regards,

--Scott

Joel Amoussou wrote:
> Hi All,
>
> The main strength of DITA is its extensibility. One of the benefits of
> DITA specialization is that it allows the reuse of processing code (e.g.
> XSLT stylesheets) across specializations through a fall back mechanism to
> base types. The lack of specialization in S1000D is cited as one of its
> main drawbacks. However the combination of XML Schema 1.1 substitution and
> inheritance, XPath 2.0, and XSLT 2.0 can provide a very robust
> extensibility mechanism for S1000D.
>
> Extensibility can be achieved in XML Schema using a variety of techniques
> including:
>
> 1.Wild cards via the xsd:any element
>
> 2.Subtype polymorphism via extension or restriction of a base type
>
> 3.Runtime polymorphism via xsi:type
>
> 4.Element substitution with or without abstract head elements.
>
> Let’s analyze how the later could be an alternative to the DITA
> specialization mechanism. Assume that we need to create a specialization
> of <ElementA>. We can declare <ElementA> as follows:
>
> <xsd:element name='ElementA' type='ElementAType'/>
>
> If we want to create <ElementB> and <ElementC> as specializations of
> <ElementA>, we would do the following:
>
> <xsd:element name='ElementB' substitutionGroup='ElementA'
> type='ElementBType'/>
>
> <xsd:element name='ElementC' substitutionGroup='ElementA'
> type='ElementCType'/>
>
> <ElementA> is the head of the substitution group and can be substituted
> with <ElementB> or <ElementC >. <ElementB> and <ElementC> must be of type
> <ElementAType> or a type derived from <ElementAType> by restriction or
> extension. <ElementB> and <ElementC> must also be declared as global
> elements, which is a best practice in component reuse.
>
> XML Schema 1.0 has a limitation in complex type restriction that made it
> difficult to use it for DITA specializations. That limitation has been
> fixed in XML Schema 1.1.
>
> One of the benefits of using XML Schema to model XML vocabularies (as
> opposed to DTDs or even RelaxNG), is that it is currently the “center of
> the universe” in the standardization space: XForms, XPath 2.0, XSLT 2.0,
> XQuery 1.0, WSDL, and other standards and tools depend on it. Therefore
> DTDs are a dead end in information design. One the problem with the DITA
> specialization mechanism is that it is DTD-centric, although an XML Schema
> version of DITA is also available.
>
> The next question is how can we achieve XSLT code reuse (fall back) across
> specializations “à la DITA”? Consider the following schema aware XSLT 2.0
> template with an XPath 2.0 pattern:
>
> <xsl:template match='schema-element(s:ElementA)'>
> 	<b><xsl:value-of select='.'/></b>
> </xsl:template>
>
> schema-element(s:ElementA) matches any element that is annotated as an
> instance of the type defined by the schema element declaration <ElementA>,
> and whose name is either ElementA or the name of another element in its
> substitution group. Therefore, the XSLT 2.0 pattern will also match
> <ElementB> and <ElementC>. XQuery also supports schema-aware processing
> and queries.
>
> The adoption of the XML 1.1 substitution mechanism could require a
> refactoring of both DITA and S1000D content models. However, I believe
> that the combination of XML 1.1 and schema-aware XSLT 2.0 allows us to
> achieve the benefits of specialization without resorting to DITA’s complex
> and elaborate scheme for achieving the same result with DTDs and XSLT 1.0.
>
> One way to facilitate interoperability between S1000D and DITA is to use
> S1000D element names and semantics when creating DITA specializations for
> domains such as the machine industry. The fact that the DITA Machine
> Industry SC (see
> http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=dita-machine-industry)
> is not using that approach should be a cause for concern. In fact, S1000D
> can handle the requirements of the machine industry (manufacturing system
> engineering, engine and machine construction, power plant equipments,
> etc.) with elegance.
>
> Best regards,
>
> Joel Amoussou
> http://www.efasoft.com
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dita-s1000d-discuss-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: dita-s1000d-discuss-help@lists.oasis-open.org
>
>   

begin:vcard
fn:Scott Hudson
n:Hudson;Scott
org:Flatirons Solutions
adr:Suite 200;;4747 Table Mesa Drive ;Boulder;CO;80305;USA
email;internet:scott.hudson@flatironssolutions.com
title:Consultant
tel;work:303-542-2146
tel;fax:303-544-0522
tel;cell:303-332-1883
url:http://www.flatironssolutions.com
version:2.1
end:vcard