- From: <bugzilla@wiggum.w3.org>
- Date: Wed, 05 Sep 2007 13:52:39 +0000
- To: www-xml-schema-comments@w3.org
- CC:
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