W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > January to March 2008

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

From: <bugzilla@wiggum.w3.org>
Date: Mon, 14 Jan 2008 16:37:41 +0000
To: www-xml-schema-comments@w3.org
Message-Id: <E1JESJh-00069U-4B@wiggum.w3.org>


------- Comment #6 from noah_mendelsohn@us.ibm.com  2008-01-14 16:37 -------
On the call last week, Henry asked me to send an email clarifying my thoughts
on this issue.  In researching the question, I realize that much of my position
has been stated in the comments above [1,2].  Since Henry seems to want another
try at netting things out, I'll try that here:

There are at least three fundamental questions, I think:

Q1. If xml:lang semantics are to be inherited for CTA, is this best viewed as
an infoset augmentation in the spirit of attribute defaulting, or is it better
to achieve this by allowing type assignments to depend on the context in which
the element appears, I.e. to allow <xs:alternative> XPaths to look up the tree?

Q2. To what extent is the necessary support best provided in the XSD
specification as opposed to in, say, a new version of the Infoset

Q3. If the preferred answer for CTA is to relax tree trimming rules, what would
we do for assertions?  It seems that those might also want to be sensitive to
the inherited semantics of xml:lang.

I'll briefly comment on these in order.

Q1 Comments:

xml:lang inheritance is not used just for validation.  One can easily imagine
lots of use cases, in databinding for example, in which an application
consuming the PSVI would welcome the availability of the inherited xml:lang
value, even if that value played no role in determining validity or type
assignment.  XQuery and XSLT also seem to be use cases in which inheriting the
value might be useful.  Those are key reasons that I prefer to think about this
in terms of infoset augmentation.  I also welcome the fact that augmentation
reduces the need to reopen the discussion of a hard-won compromise, which was
to include CTA, but with the "attributes-only" tree triming.

Q2 Comments (including sketch of a design proposal):

Michael took my comment #1 to imply that I was against changes to XSD to
support this requirement.  Not so, though the changes I think I'd prefer would
not be to the tree trimming rules.  

As an aside, I think the case can be made that xml:lang inheritance, and
perhaps other attribute inheritance, would architecturally have been better
handled in XML itself.  Perhaps some alternate syntax like <e attr!="..."/>
might have been used.  Though a bit ugly syntactically, this would have made
the inheritance work consistently regardless of whether a validation was being
performed at all, regardless of what schema language was used, etc. 
Presumably, the Infoset and XQuery data models would have reflected such

Nonetheless, I think XSD is a reasonable second-best or alternative for
signalling the inheritance of attributes, and I'm willing to invest a bit of
effort in the needed changes.

Design proposal sketch:

I certainly haven't considered this carefully, but what if we allowed on either
an attribute declaration or an attribute use (not sure which), something like:

  <attribute name="attr" valueInherited="yes" />

This could be a signal to augment the PSVI of descendent elements with the
inherited value.  Exactly which PSVI properties to set would be TBD, but it
would probably be similar to attribute defaulting. 

We would state that both assertion and CTA alternative XPaths would honor these
inherited defaults.  Perhaps we'd extend identity constraints to do the same. 
We would also have to state what the rules are in the case that the element
info item at which validation starts has a [parent].  Our precedent with
ID/IDREF is never to look outside the root of the validation for anything.  If
something like an editor is doing incremental revalidation of, say, some
particular element within a larger document, we'd have to decide whether that
processor MAY, MUST, SHOULD, or MUST NOT inherit from any xml:langs that might
be above the validation root.

Q3. As noted above, my first choice is not to reopen tree trimming at all. 
Getting the current design was a tough compromise for all concerned. 
Nonetheless, some ne members of the group favor exploring that option. 
Regarding that, my position is:

I would "lie down in the road" against:

* Letting assertion XPaths look at ancestors or siblings of the element on
which the assertion occurs.  I don't want the validation of a complex type to
be context dependent.

* Letting CTA XPaths look at descendents, other than attribute children, of the
element on which the type assignment is being done.  I'm worried about
deferring the assignment of a type until content that may be well beyond the
start tag is seen.

I would with some serious concerns about complexity consider:

* Letting CTA alternative XPaths look at ancestors.  

That last bit is what we'd need to allow the
test="ancestor-or-self::@xml:lang[last()]='ja'" that's been discussed here.


Independent of my concerns about tree trimming, doing this as an infoset
augmentation seems right to me.  I have some concern about scope creep, but
this seems like a good requirement against CTA, and if we can meet it without
serious delay to our schedule I'd be willing to support that.  I ask the group
to consider proposals like the one I've made above.

If others in the group near consensus that loosening tree trimming is a better
approach to his particular requirement, I'd with serious concerns consider
allowing ancestor references for CTA.  Unlike the infoset approach, this would
not provide similar function for assertions, and I remain very much against
allowing ancestor references on assertions, as that would make complex types
context-dependent.  That said, I hope the group will not use this issue as an
opening to reconsider our compromise on tree trimming.

I note that in comment #5 [3] the original commentator states:

"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."

So, as I understand it, either approach would be acceptable.


[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=5003#c1
[2] http://www.w3.org/Bugs/Public/show_bug.cgi?id=5003#c4
[3] http://www.w3.org/Bugs/Public/show_bug.cgi?id=5003#c5
Received on Monday, 14 January 2008 16:37:44 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:50:07 UTC