- From: Laura Holmes <holmes@google.com>
- Date: Tue, 24 Jul 2007 18:54:08 -0400
- To: public-mobileok-checker <public-mobileok-checker@w3.org>
- Message-ID: <135a9f560707241554i166d616arb9bdb4e526611c00@mail.gmail.com>
Hi all, I just wanted to run some changes by you all and get some feed back. Currently, I'm working on the ExternalResourcesTest and am running into conditions that haven't been accounted for in the existing code. These conditions include: 1) counting references contained in objects that are not jpeg or gif: there are many other image types and other types of objects (such as applications or audio) that may be included on a page. I'm assuming that we want to include these references even if they can't be rendered on a mobile phone due to a comment made regarding nested objects: "For nested objectelements, count only the number of objects that need to be assessed before content matching the request header defined in *2.3.2 HTTP Request*<http://www.w3.org/TR/mobileOK-basic10-tests/#http_request>is found." So, we want to assess other content types other than jpeg and gif when counting external resources. 2) keeping track of unique references to resources that are other than jpeg or gif: If two references are made in the primary document to the same image, it is only counted once, but if we reference the same image in css, we currently don't have a way of tracking this. 3) references contained in nested objects are counted regardless of whether or not the reference is actually reached: We only identify object nodes by name, not in serial order. Here are my proposed changes I want to make, which would entail changing the shape of the moki doc a bit: We create an ArrayList of URIs that is maintained throughout the entirety of the parsing process. When a reference to a resource is encountered, we check to see if the list already contains that URI. This list will contain a list of all the resources contained in both the primary doc and css files. At the end of the parsing process, we can add an additional node to any location in the moki that states the length of the list (i.e. how many unique resources were encountered). I propose adding this as it's own node under moki, as it spans information in the primary doc, images, and css. Because we only want to record the number of unique references, I can't see any other way to pull it from the moki document using xsl. I'm open to any other suggestions. As to the nested object problem, I'm at a loss for solutions given our current implementation of the DOM. Suggestions? Thanks for your input in advance, Laura
Received on Tuesday, 24 July 2007 22:54:25 UTC