This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Hi all, To have the discussion on conformance started / continued: Here is a proposal for two ITS products. This issue is related to the conformance issue. "ITS markup declarations": This product encompasses the XML DTD, XML Schema or RELAX NG schemata for ITS. The usage of this product is integration into an existing or new schema. As for conformance: A schema is conformant, if it allows all data category and selector attributes at all elements in the schema, and the <documentRules> element at at least one element. "ITS processor": This product processes ITS markup in document or schemas. "ITS markup" encompasses both data category and selector attributes, and the elements like <documentRule>. The usage of this product is currently the application of the selection mechanisms described in section http://www.w3.org/International/its/itstagset/itstagset.html#selection . As for conformance: An ITS processor is conformant, if he processes all selection mechanisms. The conformance check of "Its markup declarations" will be made by a schema validator. The conformance test for an "ITS processor" is a test suite we have to develop from now on. It must contain tests for the selection mechanisms we have defined. If the "ITS processor" passes all tests, he is conformant. Yves, if we use only these two products (which by the way are independent of each other), you don't have to be afraid of interoperability problems anymore, do you? Regards, Felix.
Two comments: A. ITS Markup: I guess we do not only deliver the markup but also the corresponding documentation, examples etc. B. ITS Processor: I guess that we do not want to deliver a processor, right? What we may want to deliver is the definition of an ITS processor. Best regards, Christian
(In reply to comment #1) > Two comments: > > A. ITS Markup: I guess we do not only deliver the markup but also the > corresponding documentation, examples etc. > > B. ITS Processor: I guess that we do not want to deliver a processor, right? > What we may want to deliver is the definition of an ITS processor. > > Best regards, > Christian Sorry for being unclear. You are absolutly right for A and B, Christian. Felix
Hi all, I thought about how to achieve the simple conformance "ITS without selector attributes". This is my solution proposal: Let's get rid of selector attributes in situ. It occurred to me that there is *no real need* for selector attributes *in situ*. Every XPath expression in an selector attribute which is in situ can be transformed into an XPath expression in an selector attribute which is at an <its:documentRule> element. Hence, my proposal: - Say in the spec that the in situ attributes are only to be used at the <its:documentRule> element, and change the markup definition in that sense (that is, the selector attributes are now not global attributes, but local ones at <its:documentRule>.) - have a conformance level which makes a schema conformant if it implements only the data category attributes, but not the selector attributes and the <documentRules> element. benefits of this change besides the conformance issue: - better validation of the attribute usage. It is not possible to use in situ *only* selector attributes. - GREAT benefit: it is now possible to say that every selector attribute value has to start with "/", since they are only dislocated. So: we can have a datatype with a regular expression like "/.*" for the selector attributes. - processing of in situ usage of ITS becomes easier. - explanation to users becomes easier: in situ we have only default selections, and dislocated we have XPath. Looking forward to discuss this via mail. Regards, Felix.
Not allowing selector in situ is certainly an interesting proposal. This would make things more difficult for any datacat applied to attributes, but since we don't encourage translatable attribute, and this would affect only the cases when we override a defined datacat this may not be to big of an issue.
(In reply to comment #4) > Not allowing selector in situ is certainly an interesting proposal. > > This would make things more difficult for any datacat applied to attributes, > but since we don't encourage translatable attribute, and this would affect > only the cases when we override a defined datacat this may not be to big of an > issue. > for a user of ITS, it would be more difficult in the sense that each time you want to express s.t. about a specific, singular attribute, you would need an <its:documentRule> element with at least two attributes: the data category attribute and the selector attribute. But the attributes would be necessary in the in situ application as well. And it would be no problem to express s.t. about attributes *in general* dislocated: <its:documentRule its:translate="yes" its:translateSelector="//img/@alt"/> for an ITS processor, I think it would make things slightly easier to have no in situ selector attributes, and the expressive power of selection would be the same.
closed during discussion at http://www.w3.org/2006/04/18-i18nits-minutes.html#item09