W3C home > Mailing lists > Public > public-multilingualweb-lt@w3.org > August 2012

Re: [ACTION 128] Add the idValue to ODD

From: Felix Sasaki <fsasaki@w3.org>
Date: Sun, 12 Aug 2012 08:09:11 +0200
Message-ID: <CAL58czrC4nkcmEevkYdp5w4ix14K2N2CtYozd+f-E71nS=dhfg@mail.gmail.com>
To: Yves Savourel <ysavourel@enlaso.com>
Cc: public-multilingualweb-lt@w3.org
Hi Yves,

2012/8/11 Yves Savourel <ysavourel@enlaso.com>

> Hi Felix,
> >> The table entry looks ok, except possibly for Overriding:
> >> I think it should be Yes.
> >
> > Shouldn't it be rather not applicable? Also, the inheritance
> > should be none, I think. Otherwise, for an input like this
> > ...
> > We have an output like this:
> > <node path="/doc/msg[1]/desc[1]" outputType="new-value-global">
> >         <output>settingsMissing_d</output>
> >      </node>
> >      <node path="/doc/msg[1]/desc[1]/em[1]" outputType="inherited">
> >         <output>settingsMissing_d</output>
> >      </node>
> > That is, the id inherits from "desc" to the child element "em".
> >
> > So we should probably change
> > "The information applies to the textual content of the element,
> > including child elements, but excluding attributes."
> > to
> > "There is no inheritance."
> > What do you think?
> Mmm... I guess I need to refresher on our two concepts of inheritance and
> overriding.
> For Overriding: If I have:
> its:idValueRule selector="//text" idValue="concat(../@name, '_t')"/>
> its:idValueRule selector="//text/quote" idValue="../@id"/>
> Shouldn't the second rule override the first one? I think it should.

If there is no inheritance, that is from "text" selected in the first rules
to "quote" selected in the second rule, there won't be a conflict, so no
need for overriding.

> For inheritance: I think I see what you mean: the ID is only valid for the
> whole content and cannot be applied *just* to a specific child element. But
> at the same time it's true that the information does apply to the child
> elements. So the original statement is not wrong, is it?

I think above is wrong - see "Elements within text". Here we say:
"The Elements Within Text data category can be expressed with global rules,
or locally on an individual element. There is no inheritance."

This does mean that here
<ftnote><p its:withintext="nested">Some <b>nested</b> text.</p></ftnote>
"p" is "nested", and that information applies only to "p" and not to "b".
Nevertheless, if you want to make use of "p" in an application, you would
want to pass
<p its:withintext="nested">Some <b>nested</b> text.</p>
to that application, that is including the nested markup.

> But I'm probably missing something.

I think the difference is between: what values of the data category inherit
in the tree, and what pieces of (nested + attribute) content (and markup)
would be passed to an id value enabled application. In other data
categories like "term" (also "no inheritance" and "overriding is not
applicable"), we would pass the complete "term" element
<term def="TDPV">discoursal point of view</term>
(from example 34) to an application, including the "def" attribute. But the
"def" attribute itself wouldn't be a term

It is like CSS: in an example like this

<html xmlns="http://www.w3.org/1999/xhtml">
        <title>CSS inheritance</title>
        <style type="text/css">
            div { border-width:1em; border-style: solid; border-color: red;}
            <span>Some <code>span</code> text inside <code>div</code>.
            <p>This paragraph inside <code>div</code> has no border, since
border doesn't inherit.</p>
The setting "this element has a border border" information does not inherit
from "div" to child elements. Nevertheless, if you want to pass all
elements with a border to an application (e.g. a brower visualizing this),
you would pass the complete "div" element with everything inside to it.

We probably need to make this much clearer in the spec.



> Cheers,
> -ys

Felix Sasaki
DFKI / W3C Fellow
Received on Sunday, 12 August 2012 06:09:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:31:50 UTC