[Bug 5003] Applicability of <alternative> element to xml:lang

http://www.w3.org/Bugs/Public/show_bug.cgi?id=5003





------- Comment #1 from noah_mendelsohn@us.ibm.com  2007-09-05 13:52 -------
>From the original bug report:

> however, this only makes sense if the information
> of xml:lang is inherited for type-checking, that
> is: test="@xml:lang='ja'" needs to be interpreted
> as test="ancestor-or-self::@xml:lang[last()]='ja'"
> . Could you make sure that this is possible?

I think this is asking schema to resolve a problem that should in fact be
resolved at the Infoset level.  The request is basically that the values of
xml:lang be inherited through the document tree, much as xml namespace prefix
bindings are.  The Infoset does not currently provide for such inheritance; 
xml:lang attribute values are attached only to elements on which they appear as
children, not to descendents of those elements.

While it might be appealing from a user's point of view to allow navigation to
ancestor elements in <alternative> XPaths (or in assertions for that matter),
doing so would make element declarations (or in the case of assertions type
definitions) context dependent in a manner that I think is undesirable.  For
example, it would complicate the definition of what it means to start
validating an arbitrary element information item against a corresponding
element declaration:  would one need to navigate to that elements' ancestors to
determine the right values for xml:lang?  Would it be necessary to generalize
this mechanism to other attributes?

I think the right way to handle this, if the need is there, is to specify a
transform on the Infoset that would take as input the obvious Infoset that
results from parsing an XML document per today's specification, and produces an
infoset that decorates descendent elements with xml:lang as appropriate.  This
transform could be applied in places where the user wishes to have that
semantic (or a different property could be invented, and we could then consider
extending XPath to address that additional property).  I think this is a better
solution architecturally then complicating schema;  presumably the reason that
this feature is requested is that the instance itself is intended to have
inheritance semantics that the Infoset is failing to reflect.

Noah

Received on Wednesday, 5 September 2007 13:52:42 UTC