Michael Kay
> If you don't think it's a problem in practice, what about taking the
> xml-to-xhtml XSLT associated with the xmlspec DTD, and change it so
> that multilingual input is output with the correct xml:lang attributes
> (but without having xml:lang on every element if not necessary).
>
There are lots of things in XSLT that aren't easy, such as processing CALS
table models. But on the scale of problems this one is by no means
difficult: for example it can be done by running a three-phase
transformation in which a pre-processing phase adds redundant xml:lang
attributes: <xsl:template match="*">
<xsl:copy>
<xsl:copy-of select="@* | ancestor-or-self::*/@xml:lang[last()]"/>
<xsl:apply-templates/>
</xsl:copy>
</xsl:template>
and a post-processing phase removes redundant xml:lang attributes:
<xsl:template match="*">
<xsl:copy>
<xsl:copy-of select="@* except @xml:lang[. =
ancestor::*/@xml:lang[last()]]"/>
<xsl:apply-templates/>
</xsl:copy>
</xsl:template>
When I said it doesn't seem to be a problem in practice, I meant that I
don't see evidence of lots of users trying to do this and complaining that
it's difficult. I see a lot more complaints about the difficulty of handling
CALS table models. For a problem that doesn't arise often in practice, a
solution in 12 lines of code seems good enough.
Inherited attributes are a bit of an oddity. Formally, there is no such
thing as an inherited attribute, it's only a design convention, and there
are lots of different variations on it - xml:space, xml:base, and xml:lang
work quite differently from each other. Without a formalisation of inherited
attributes in the data model and in the XML Schema type system, it's not
easy to come up with language constructs that would be generic enough to be
useful, and an ad-hoc solution for one particular attribute would be really
bad design, especially in the absence of any evidence of a pressing user
problem. |