Re: [ACTION-217] - StorageSize linebreaks

Hi Yves, all,

thanks, Yves, that's a good point. The best thing would be to go through
all new data categories and check that this sentence "Pointing to existing
information is not possible for data categories that express a closed set
of values" is reflected, that is: pointer attributes where it makes sense.
Any volunteers?

- Felix

2012/9/16 Yves Savourel <ysavourel@enlaso.com>

> Hi Felix,****
>
> ** **
>
> That is a good point.****
>
> We don’t really need a pointer for lineBreakType since the values could be
> mapped directly in global rules.****
>
> ** **
>
> Looking at the text you cited below, I wonder about LocaleFilter. Is the
> value of localeFilterList can be considered a close set of values? It’s
> really an expression.****
>
> ** **
>
> -ys****
>
> ** **
>
> ** **
>
> *From:* Felix Sasaki [mailto:fsasaki@w3.org]
> *Sent:* Saturday, September 15, 2012 4:46 PM
> *To:* Yves Savourel
> *Cc:* public-multilingualweb-lt@w3.org
> *Subject:* Re: [ACTION-217] - StorageSize linebreaks****
>
> ** **
>
> Hi Yves,****
>
> ** **
>
> sounds good. I'm just wondering whether we need the "pointer" attribute -
> for other global rules with a fixed set of values we didn't have them and
> also said that in the spec:****
>
> ** **
>
> "Each data category allows users to add information to the selected nodes
> except for language information<http://www.w3.org/International/multilingualweb/lt/drafts/its20/its20.html#language-information>.
> Pointing to existing information is not possible for data categories that
> express *a closed set of values*, that is: Translate<http://www.w3.org/International/multilingualweb/lt/drafts/its20/its20.html#trans-datacat>
> , Directionality<http://www.w3.org/International/multilingualweb/lt/drafts/its20/its20.html#directionality>
> , Locale Filter<http://www.w3.org/International/multilingualweb/lt/drafts/its20/its20.html#LocaleFilter>,
> andElements Within Text<http://www.w3.org/International/multilingualweb/lt/drafts/its20/its20.html#elements-within-text>
> ."****
>
> ** **
>
> Above list also needs to be updated, it seems.****
>
> ** **
>
> Best,****
>
> ** **
>
> Felix****
>
> ** **
>
> 2012/9/15 Yves Savourel <ysavourel@enlaso.com>****
>
> Hi all,
>
> Here is an initial proposal for dealing with the type of line breaks for
> the Storage Size data category:
>
> For the global rule we would add:
>
> None or exactly one of the following two attributes:
>
> - lineBreakType="lf|cr|crlf|nel" where:
>
> lf means the linebreak is U+000A (e.g. Linux)
> cr means the linebreak is U+000D (e.g. Macintosh)
> crlf means the linebreak is U+000D followed by U+000A (Windows)
> nel means the linebreak is U+0085 (e.g. EBCEDIC systems)
>
> (Note: I don't include 'rs' for U+001E used in pre-POSIX QNX systems as it
> is obsolete)
> (Note: I've included 'nel' for EBCEDIC, but I really wonder about this)
>
> - lineBreakTypePointer: a relative XPath expression pointing to an
> attribute or element with the exact same semantics as lineBreakPointer.
>
>
> For the local markup we would add:
>
> An optional lineBreaType="lr|cr|crlf|nel" (same as above).
>
> The default value would be 'lf' in all cases.
>
>
> Cheers,
> -yves
>
>
> ****
>
>
>
> ****
>
> ** **
>
> --
> Felix Sasaki****
>
> DFKI / W3C Fellow****
>
> ** **
>



-- 
Felix Sasaki
DFKI / W3C Fellow