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

Re: Make its:param optional?

From: Felix Sasaki <fsasaki@w3.org>
Date: Sun, 14 Oct 2012 20:38:32 +0200
Message-ID: <CAL58czpeZWA8tD6RRSvckyDkkG8DfP7nd+Z8t_EVBvU9ndKrKw@mail.gmail.com>
To: Shaun McCance <shaunm@gnome.org>
Cc: Yves Savourel <ysavourel@enlaso.com>, public-multilingualweb-lt@w3.org
Hi Shaun, all,

it seems the essence of the "warning" is what you wrote below - changed a
bit:

its:param is a mechanism for situations in which project or partner
specific workflows need parameters for XPath. When creating ITS global rues
for interchange (for example, if you create an XML vocabulary and you
provide reference ITS rules for it), then you should avoid its:param.

Would that be OK with everybody?

Best,

Felix

2012/10/12 Shaun McCance <shaunm@gnome.org>

> On Fri, 2012-10-12 at 05:31 -0600, Yves Savourel wrote:
> > Hi Felix, Jirka, Shaun, all,
> >
> > > OK, so we keep its:param I guess.
> > > Would it be OK to add the following note to the its:param section:
> > >
> > > its:param adds flexibility in real-life situations. However in general
> > > it is recommended not to use its:param. It is disallowed in CSS,
> > > see section 5.3.5, since the current version of CSS does not allow
> > > variable bindings.
> >
> > Hum, I have nothing about a note touching on the difficulty of
> implementation. But the CSS part, I think, is a different story. It sounds
> like the fact its:param is not part of ITS-with-CSS is a valid reason to
> not use it with XPath either. That's a bit strong for a best practice.
> >
> > -- a) Likely, its:param is going to be used only in the cases where
> > there is no other way to write the rule. So it'll be for use cases
> > where you can't use CSS anyway. So re-suing those rules doesn't really
> > applies.
>
> I think its:param is useful for very specific stuff. And hopefully
> when you're dealing with specifics, you know your ITS processing
> tool and what it can do.
>
> But if you're creating ITS files for interchange (for example, if
> you create an XML vocabulary and you provide reference ITS rules
> for it), then you should avoid its:param.
>
> > -- b) You can make a rule that uses its:param not use it by just
> > replacing the variable by a given value, then you convert that to CSS.
> > It's not much more work than actually converting the XPath selector to
> > a CSS selector. Sure it's not a 1-to-1 port of the rules, but the
> > point is that first: its:param is not a show-stopper, and second: if
> > someone wants to convert XPath-based rules to CSS-based rules, the
> > hard part is to convert XPath to CSS, not its:param.
> >
> > -- c) Why its:param cannot be used in CSS in the first place? CSS may
> > not have a binding mechanism but what's preventing CSS implementers to
> > use the mechanism Jirka described in
> >
> http://lists.w3.org/Archives/Public/public-multilingualweb-lt/2012Oct/0148.html?
> In most programming languages it's simple to substitute the variables by
> their values before applying the selectors. If I were an implementor of a
> CSS-based ITS engine I would be puzzled by the section 5.3.5.
>
> There's just no agreed-upon syntax for variables in CSS selectors.
> You could pretend that $ is an XPath-like variable sigil and do a
> substitution pre-pass, but it's really not a CSS selector anymore.
>
> I'm not aware of any efforts to introduce variables for selectors.
> Jirka mentioned CSS variables might exist in the future, but the
> only effort I know of is about adding variables in properties,
> not selectors:
>
> http://dev.w3.org/csswg/css-variables/
>
> > -- d) Do we have anyone implementing ITS with CSS selectors? If we
> > don't at this stage, I wonder if any CSS-based argument is applicable.
>
> I implemented it in Jits, except without CSS selector namespace
> support, because querySelectorAll doesn't do namespaces. But I'm
> not actually using ITS files with CSS selectors for anything.
>
> --
> Shaun
>
>
>
>


-- 
Felix Sasaki
DFKI / W3C Fellow
Received on Sunday, 14 October 2012 18:39:00 UTC

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