W3C home > Mailing lists > Public > public-mobileok-checker@w3.org > July 2007

Proposed changes to Moki - External Resources Test

From: Laura Holmes <holmes@google.com>
Date: Tue, 24 Jul 2007 18:54:08 -0400
Message-ID: <135a9f560707241554i166d616arb9bdb4e526611c00@mail.gmail.com>
To: public-mobileok-checker <public-mobileok-checker@w3.org>
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
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,
Received on Tuesday, 24 July 2007 22:54:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:21:18 UTC