[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita-s1000d-discuss] DITA specialization mechanism, revisited
Scott,
Your question: "should it be a DITA SC, or should there be a full TC established to address interoperability between the standards?"
Scott
Tsao
Boeing IT Architecture
and Information Management
-----Original
Message-----
From: Scott Hudson [mailto:scott.hudson@flatironssolutions.com]
Sent: Friday, February 09, 2007 8:33 AM
To:
joel@efasoft.com
Cc: dita-s1000d-discuss@lists.oasis-open.org
Subject: Re:
[dita-s1000d-discuss] DITA specialization mechanism, revisited
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-machin
> e-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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]