W3C home > Mailing lists > Public > public-multilingualweb-lt@w3.org > January 2013

[LT-Web] ITS 2.0 parsing question

From: Mārcis Pinnis <marcis.pinnis@Tilde.lv>
Date: Fri, 4 Jan 2013 18:05:34 +0200
To: "public-multilingualweb-lt@w3.org" <public-multilingualweb-lt@w3.org>
CC: "Felix Sasaki (fsasaki@w3.org)" <fsasaki@w3.org>, Pēteris Ņikiforovs <peteris.nikiforovs@Tilde.lv>
Message-ID: <AC6FD4BB9BB02540AC7322091A6C3B5472B0D6ABF6@postal.Tilde.lv>
Hi everyone,

First of all ... Happy New Year to everyone.

We are going through various ITS 2.0 Test Suite examples and we have a question regarding pointers.

For instance, for termInfoPointer, (see the example below) if we use an XPath like this: „../h:ul/h:li”, it selects all „h:li” nodes that there exist (in h:ul tags, of course). The question is, should that be valid for termInfoPointer or should the content provider ensure that the XPath expression resolves to a single node as ITS 2.0 says:

A termInfoPointer attribute that contains a relative selector<http://www.w3.org/International/multilingualweb/lt/drafts/its20/its20.html#selectors> pointing to ***a node*** that holds the terminology information.

So if pointing to multiple nodes is wrong can other implementers share what they do in such a situation (ignore that there is a content error or throw an exception and require valid content)? I guess the simplest solution is to tell users that the document is invalid, however, we could also ignore such errors and allow the system to work with multiple nodes.

<!DOCTYPE html>
  <script type="application/its+xml">
  <its:rules xmlns:its="http://www.w3.org/2005/11/its" xmlns:h="http://www.w3.org/1999/xhtml" version="2.0">
  <its:termRule selector="//h:h1" term="yes" termInfoPointer="../h:ul/h:li"/>
     <li>Name of the operating system</li>
     <li>Name of a custom Linux kernel</li>
     <li>Name of the mobile phone</li>

In the example termInfoPointer points to multiple <li> tags with "../h:ul/h:li", but the specification requires „a node”.

Best regards,
Mārcis ;o)
Received on Friday, 4 January 2013 16:06:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:32:00 UTC