- From: Felix Sasaki <fsasaki@w3.org>
- Date: Tue, 31 Jan 2006 23:14:11 +0900
- To: "public-i18n-core@w3.org" <public-i18n-core@w3.org>
Hi all, As an input for todays call: Below is the current state of the CDF / CSS selectors discussion. I added the end of the threads below, and the current position of the working groups. To read this fast, please search for "reject" or "partially". Regards, Felix. ------------------------------------------ CSS selectors (overview of comments at http://www.w3.org/International/reviews/0601-css3-selectors/ ) ------------------------------------------ 1 It would be useful to have a non-normative reference to XPath, since there is a lot of overlap in functionality between CSS and XPath, even if the application scenarios (dynamic versus static environment) are different. http://lists.w3.org/Archives/Public/public-i18n-core/2006JanMar/0082.html Rejected: "XPath doesn't reference Selectors either." 2 Your notion of "type": It would be good if you note that there are different notions of types, e.g. the element name as a type (as in the case of CSS) as the XML Schema notion of types. http://lists.w3.org/Archives/Public/public-i18n-core/2006JanMar/0083.html Rejected: "element type is a well-established term ..." 3 This document, from the title appears to be about CSS specifically, not a generic styling language, so the text in 6.1.1 for example seems strange: "he mechanism for declaring a namespace prefix is left up to the language implementing Selectors. In CSS, such a mechanism ..." http://lists.w3.org/Archives/Public/public-i18n-core/2006JanMar/0084.html Rejected: WG sees no confusion, only the document location is confusing, but it cannot be changed. 4 "E[hreflang|="en"] an E element whose "hreflang" attribute has a hyphen-separated list of values beginning (from the left) with "en"" I think this should be made more generic, ... http://lists.w3.org/Archives/Public/public-i18n-core/2006JanMar/0085.html WG has changed E[hreflang|="en"] to E[foo|="en"] in section 2. 5 Which version of XML Namespaces (and XML) is supported by the document? http://lists.w3.org/Archives/Public/public-i18n-core/2006JanMar/0031.html Partially accepted: "All of them. To make this clearer we have made the references to [XMLNAMES] explicitly informative and made the prose say "e.g." before mentioning [XMLNAMES]." 6 In 6.1.1, it should be made clear that the styling language (e.g. CSS) must provide a prefix binding mechanism. It is also unclear what effect, if any, namespace declarations in the document being styled have on prefixes used in the stylesheet. http://www.w3.org/International/reviews/0601-css3-selectors/ http://lists.w3.org/Archives/Public/public-i18n-core/2006JanMar/0088.html Rejected: "Since it is possible to use Selectors with languages that do not have namespaces at all (e.g. the language most used with CSS, namely HTML4), we do not agree that such a prefix binding mechanism must be provided." 7 hreflang is used in a examples with the HTML link element. I'm always wary of the hreflang attribute's usefulness, and the meaning of that attribute in XHTML2 will change, and I'm also struggling to see an application for using it to style the link element content in current implementations. [...] http://lists.w3.org/Archives/Public/public-i18n-core/2006JanMar/0089.html Accepted: "We have changed the example from using a <link> element to using an <a> element in section 6.3.1." 8 "as described in RFC 3066 ([RFC3066])" Recommend 'as described in RFC 3066 ([RFC3066]) or its successor'. Note that its successor is currently only awaiting the IETF editor to assign an RFC number, but has been approved by the IETF to succeed RFC3066. Note also that it will allow for additional subcode values, such as script identifiers. http://lists.w3.org/Archives/Public/public-i18n-core/2006JanMar/0091.html Accepted: "We have made this change. Note that this is just an informative reference, and therefore it really makes no difference either way to the normative requirements of our draft." 9 "Similarly, the following selectors represents a DIALOGUE element" One of the 's's in 'selectors represents' has to go. http://lists.w3.org/Archives/Public/public-i18n-core/2006JanMar/0092.html Accepted: "The working group discussed this, and agreed to make the subject and verb agree by using the plural, i.e., "selectors represent"." 10 "including "en", "en-US", and "en-cockney"" Since en-cockney is not currently an allowable value according to RFC3066, I suggest you use something different, such as en-GB (UK English). http://lists.w3.org/Archives/Public/public-i18n-core/2006JanMar/0093.html Accepted: "The working group discussed this. We used "en-scouse" instead." 11 On substring matching: it would be highly desireable to have regular expression facilities instead of substring matching. http://lists.w3.org/Archives/Public/public-i18n-core/2006JanMar/0109.html Rejected: "We will consider this for a future version of Selectors. However, at this time it seems too late to add new (unimplemented) features to this draft." 12 Your requirements for handling of default attributes corresponds to a non-validating XML processor, which you might make explicit. See XML conformance level. http://lists.w3.org/Archives/Public/public-i18n-core/2006JanMar/0100.html Half accepted: "[...] I have added "This corresponds to the behaviour of non-validating processors as defined by the XML specification." to the note in section 6.3.4." 13 You use the name "period" for the character U+002E, which is the Unicode 1.0 name for "full stop". You might change the naming or make the reference to the Unicode version for this naming explicit. http://lists.w3.org/Archives/Public/public-i18n-core/2006JanMar/0101.html Accepted 14 "in the same way as if performed by the '|=' operator in attribute selectors" I think it is important to clarify that the behaviour of :lang and |= is significantly *different* with regards to inherited language values. This is not explained as far as I can see, but my understanding is that it is intended. http://lists.w3.org/Archives/Public/public-i18n-core/2006JanMar/0102.html Accepted: "I have added the following paragraph to 6.6.3: The difference between :lang(C) and the '|=' operator is that the '|=' operator only performs a comparison against a given attribute on the element, while the :lang(C) pseudo-class uses the UA's knowledge of the document's semantics to perform the comparison." 15 "based solely on the identifier C being either equal to, or a hyphen-separated substring of," Actually it has to match the hyphen separated values starting from the beginning. ie. 'AU' cannot match 'en-AU'. Perhaps this can be expressed in a similar way to E[foo^="bar"], ie. 'based solely on the identifier C being either equal to, or exactly beginning the element's language value'. Or you could perhaps define it in a similar way to XPath, which says "s the same as or is a sublanguage of the language as defined by RFC 3066 or its successor". This may be safer, as the matching rules may change slightly with the successor to RFC 3066. http://lists.w3.org/Archives/Public/public-i18n-core/2006JanMar/0103.html Partially accepted: "I have changed the definiton to read: Whether an element is represented by a :lang() selector is based solely on the element's language value being exactly equal to the identifier C, or beginning with the identifier C immediately followed by "-" (U+002D), in the same way as if performed by the '|=' operator in attribute selectors." "We specifically do not wish to refer to RFC 3066 or its successors because regardless of those specifications changing the rules, the rules for matching of the |= and :lang() forms in Selectors will not change. If it did change it would cause backwards compatibility issues." 16 This section should state that the matching of language values is case-insensitive, eg. en-gb is the same as en-GB. No reply so far. 17 "the language is determined by a combination of the lang attribute, the meta element, and possibly by information from the protocol (such as HTTP headers)." I suggest at least make this "the language is determined by use of the lang attribute, and possibly by information from the meta element and the protocol (such as HTTP headers)." http://lists.w3.org/Archives/Public/public-i18n-core/2006JanMar/0104.html Accepted, change made 18 "represent an HTML document that is in Belgian, French, or German" Need to remove the comma after Belgian. To be absolutely clear here, you could say "French as spoken in Belgium, or German". There are two occurences of this error in this paragraph. Another possibility would be to uppercase the BE, to help show that this is a country rather than a language code. http://lists.w3.org/Archives/Public/public-i18n-core/2006JanMar/0105.html Accepted 19 What is the intention of this section 6.6.6? http://lists.w3.org/Archives/Public/public-i18n-core/2006JanMar/0106.html Explained: "It is an empty section with the intention of introducing no normative conformance criteria." 20 There should be a definition of what constitutes a 'letter'. We propose that this should be the first *grapheme cluster* (after any punctuation such as you list). [...] No reply from the Working Group, only from Daniel Glazman (bottom of http://lists.w3.org/Archives/Public/public-i18n-core/2006JanMar/0046.html ): "> #20 oh, no please... That's certainly something I don't want > us to dive into. > We could link to a definition, but adding one ourselvesis too > dangerous." 21 It may be useful to provide an example to clarify the bidirectional ordering point. We could probably do that for you, if needed. Presumably, in ordinary right to left text, the user agent would be expected to apply the styling to the character on the right of the line. Note that this (presumably) applies really to Hebrew but not Arabic, since the latter script is cursive. No reply. 22 Reference to character model in the bibliography, but not in the text. http://lists.w3.org/Archives/Public/public-i18n-core/2006JanMar/0107.html Reference in the bibliography removed. 23 Please add a link to the Syntax document, and make it a dependency. http://lists.w3.org/Archives/Public/public-i18n-core/2006JanMar/0108.html Rejected: "I have made no change to the spec in response to this comment. In the likely event that this does not satisfy your request, please explain exactly what it is you would like to see, with your reasoning." ------------------------------------------ CDF (overview of comments at http://www.w3.org/International/reviews/0601-cdf/Overview.html and http://www.w3.org/International/reviews/0601-cdfcore/ ) ------------------------------------------ cdr-1 As for the topic of pishing: Please add a reference to utr 36 and utr 39, which provide possible solutions for the problems you are mentioning. no reply. cdr-2 You write: "For example: XML 1.1 or HTML documents tied through hypertext reference producing as many DOM linked to one another." What is the relation between versions of XML and XML namespaces in this scenario? E.g what happens, if an XML 1.0 document references an XML 1.1. document? It might be that this depends on the languages being compounded, but you should have general guidelines for (new) languages as well. http://lists.w3.org/Archives/Public/public-i18n-core/2006JanMar/0120.html "Why would anything specific happen? I do not really understand what namespaces have to do with two documents that are only bound to each through a reference." cdr-3,4: no reply. cdr-5 If you ask an SVG document about language information, and the document is inside an HTML document, the xml:lang attribute in the HTML applies to the SVG as well. It seems that the compounding specs should say: \"You should get the same results for both inclusion and referencel.\" http://lists.w3.org/Archives/Public/public-i18n-core/2006JanMar/0127.html Rejected: "The WG has just discussed this, and we feel that for the CDR case - which is all the current set of Last Call drafts cover - the value of the xml:lang attribute in any containing HTML should *not* apply to children, because it isn't authoritative (as described in the TAG's finding on authoritative metadata[1]) as a result of requiring multiple messages to assemble the compound document. Consider, for example, that the child document might be returned with an HTTP message which includes a Content-Language header (sec 14.12 of RFC 2616) with a (authoritative) value inconsistent with that specified by the xml:lang attribute. More generally too, content may be retrieved from multiple domains over which the author of the containing document has no control, and therefore propagating the value of attributes like xml:lang doesn't seem appropriate." Martin's reply: "I have to agree with Mark here. It is very important to make clear that xml:lang inherits inside the XML document. But it would not be appropriate to make it apply to documents that are just referenced. This is similar to the HTML case, where html:lang on a frame document never applied to the individual frame contents." cdf-core: no replies so far.
Received on Tuesday, 31 January 2006 14:14:29 UTC