- From: Felix Sasaki <fsasaki@w3.org>
- Date: Tue, 12 Dec 2006 10:37:51 +0900 (JST)
- To: public-i18n-core@w3.org
Some input for todays discussion, see http://lists.w3.org/Archives/Member/member-i18n-core/2006Dec/0013.html: I'm trying to understand what we want to achieve here: 1) Should a PLS processor be able to "understand" xml:lang or the dir attribute (i.e. do s.t. useful with them), or 2) Should an author of PLS documents just be able to use these attributes? In the case of 2), a different application would make use of the attribues, e.g. an HTML browser which gets (X)HTML, generated via XSLT from the PLS source. The PLS draft says in sec. 4.8: "Because the examples are explicitly marked, automated tools can be used for regression testing and for generation of pronunciation lexicon documentation." in other words: there is no specific processing requirement for the (textual or complex, i.e. with markup) content of the <example> element. Hence, I think we can't really push for 1). Now, if we push for 2), the next question is: 2a) Do we want xml:lang and the dir attribute, and span element explicitely in the PLS schema, or 2b) Do we just want to make sure that an PLS author does not get punished by an validation error if he uses these attributes and / or span? PLS uses RELAX NG as a schema language, which gives you the following way to realize 2b): element example { attribute * - (pls:*) { text }*, (text | anyElement) } anyElement = element * - (pls:*) { (attribute * - (pls:*) { text } | text | anyElement)* } This reads as: the <example> element can contain any attribute except from the pls namespace (expressed via "attribute * - (pls:*)"), and mixed content. In the mixed content, there can be "text" or "anyElement", that is: any element except from the pls namespace (expressed via "element * - (pls:*)"), again with any attribute from the PLS namespace and mixed content. If we agree on 2 as the way to go, and the PLS folks refrain to do 2a), I would propose 2b) . Felix
Received on Tuesday, 12 December 2006 01:37:55 UTC