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

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


fabio@cs.unibo.it changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fabio@cs.unibo.it




------- Comment #11 from fabio@cs.unibo.it  2008-01-17 18:17 -------
Hello, 

My reading of Noah's comment [6] is that we have three possible ways to solve
the xml:lang issue proposed by Felix [1]: 

* We could augment the Infoset to include room for xml:lang
* We could augment the Infoset to include room for inherited attribute values
* We could relax the tree trimming rules adopted for CTA to allow for upward
sneaking. 

Please allow me to give you my .5 cents on the issue (i.e., half a cent, which,
although being euro cents, so somewhat higher than .7 US cents, is still way
lower than 5 cents even US). 

I first will note my strong opposition to any augmentation of the Infoset to
deal with specific instance-level attributes, even when they belong to
privileged namespaces such as xml. It is just wrong both to grant special
status to some namespaces and to cut out exceptions for this or that special
case. I think that the important lesson to remember whenever these situations
are known is that they exemplify issues that may be found in any vocabulary,
and that they are more prominent and urgent, but not intrinsically special and
different, when they happen to important vocabularies. Extending the infoset
for xml:lang would provide a solution for this specific case, but not for the
myriads of other identical situations of lesser vocabularies. 

On the second bullet, inherited attribute value, I am expressing my deep
concerns about introducing a new untested concept out of the blue just to
provide support for the issue at hand. I see at least three problems with this:
- first of all, let me point out similarities and differences with precedents,
such as the #CURRENT specification in SGML attributes, which would require a
missing attribute to assume the value of an attribute with the same name
appearing somewhere before (rather that upward) to the current element; several
reasons, mostly having to do with visibility and necessity of such feature,
have made it disappear in XML, and I don't recall damp eyes about this: let us
think about this carefully. 
- Secondly, it introduces an unjustified differentiation between elements and
attributes, which were carefully drafted out of the previous versions of the
XSDL language: it would now become a relevant deciding factor in the perennial
element/attribute discussion to have some special properties applicable to
attributes and not to elements: let us think about this carefully. 
- Finally, I don't think we are ready to face the impact of inherited
attributes values to the rest of the language. A few examples: do we allow
inheritance on attributes of type ID? On attributes on which unicity
constraints exist? On local attributes? On nillable attributes? Is inheritance
shared only among elements that explicitly define such attribute, or would it
be available on elements that do not define it? On elements that block it? An
intermediate element that does not allow the inherited attribute would or would
not block inheritance? Who wins between an inherited value and a default value?
If I have a global and a local definition of an attribute with the same name
and the same type, would they participate to the inheritance if they nested?
Would two local attributes inherit from each other? I could go on.  Let us
think about this carefully. 
In short, we don't have time to think about it carefully, and it seems to me
that the only real justification for it is the desire to not mess again with
the tree trimming compromise. A weak reason, seems to me. 

Finally: relax tree trimming rules. As Noah notices, 

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

It will not come as a surprise to any of you that I am among those who would
favor exploring that option. let me summarize: 
* Does not create a special case for a specific attribute or a specific
namespace. 
* Does not create a spurious distinction between elements and attributes. 
* Does not create ambiguous interaction patterns with other features of the
language, including local/global definitions, defaults, uniqueness,
nillability, etc. 
* Does not require new syntax
* Does not require new text in the draft
* Does not provide a better narrative than "we weren't able to think of a more
elegant solution so we decided to work around the specific use case"
* Does provide a reasonable solution for this and many similar cases
* Does show a way forward towards the removal of artificial constraints in XSDL
constructs
* Does provide a reasonable narrative in terms both of reuse of existing
constructs and of general applicability to a class of use cases. 

In a separate message my own take at the idea of context-free validation. 

Ciao

Fabio

[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=5003#c1
[6] http://www.w3.org/Bugs/Public/show_bug.cgi?id=5003#c6

Received on Thursday, 17 January 2008 18:17:20 UTC