RE: [Serial] additional last call comment about xml:lang

Hello Michael,

Sorry for the delay of my answer.

At 10:17 04/05/07 +0100, Michael Kay wrote:

> > 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
><xsl:template match="*">
>   <xsl:copy>
>     <xsl:copy-of select="@* | ancestor-or-self::*/@xml:lang[last()]"/>
>     <xsl:apply-templates/>
>   </xsl:copy>

It turns out that this first pass can be integrated into the main pass.

>and a post-processing phase removes redundant xml:lang attributes:
><xsl:template match="*">
>   <xsl:copy>
>     <xsl:copy-of select="@* except @xml:lang[. =
>     <xsl:apply-templates/>
>   </xsl:copy>
>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.

Well, if it were only this code. But the overhead of going from a
one-pass solution to a two-pass solution is quite heavy in many
respects. It is an important barrier.

>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,

I agree. But I'm sure there are ways to do this that are not ad-hoc
for a single attribute, that can adapt to the different inherited
attributes, and that don't necessarily need to be in the data model.

I seem to remember that James Clark at one point said that having
a feature to recursively invoke XSLT (in this case on its output)
would easily solve this problem.

Regards,    Martin.

>especially in the absence of any evidence of a pressing user
>Michael Kay

Received on Tuesday, 25 May 2004 04:48:26 UTC