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

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





------- Comment #5 from fsasaki@w3.org  2007-09-13 13:40 -------
(In reply to comment #4)
> Mike Kay writes:
> 
> > Given that XSDL already augments the Infoset with
> > values for defaulted attributes, it seems entirely
> > reasonable to me to extend the defaulting
> > mechanism to allow the defaulted value to be
> > inherited from an ancestor element rather than
> > defined as a constant in the schema. (However,
> > this reopens the question of whether defaulted
> > attribute values are visible to the XPath
> > expressions used in CTA.)
> 
> Very interesting approach.  I remain opposed to having the XPath's "look"
> outside the tree of the element being validated,

I said in the initial issue description
[the information of xml:lang .... needs to be 
interpreted as test="ancestor-or-self::@xml:lang[last()]='ja'" .]
For our use case, it does not matter if XPath is really applied or if we
achieve the necessary interpretation by infoset augmentation.
So I think what you describe below would respond to our use case.

 but I am not necessarily
> opposed to saying that the Infoset transform about which I speculated could be
> included, perhaps as an option (another point of incompatibility?  Ugh.
> Anyway...) in XSD itself.  So then the XSD model would be:
> 
> * Augment infoset for defaults and inherited attributes (not sure how we'd
> specify which ones inherit, vs. special-casing just xml:lang, which seems very
> ugly).  
> 
> * State that validation uses the inherited attribute values, either for all
> purposes, or specifically for XPath data model construction.
> 
> More complexity, but if it makes users happy I might live with it.  One thing I
> like about this is that it makes streaming a bit less of a transformative
> exercise.  You just inherit the xml:lang values in the Infoset as you go.  If
> XPath has an ancestor axis, you need to notice it, and to the sort of things
> Fabio's team has proposed to turn it into a forward processing model.
> 
> So, I'm not strongly in favor, but not strongly opposed.
>

Received on Thursday, 13 September 2007 13:40:44 UTC