RE: Sketch of documentation for mobileOK Basic implementation

Hi everyone,

Abel and I have just been talking to our workmate Diego Berrueta, member
of Semantic Web Deployment working group, and he has clarified some
stuff around RDF, HTTP-in-RDF and some other semantic web stuff that is
surrounding us.

First of all, it is (obviously) true that XPath is not useful when
dealing with RDF, although SPARQL might be useful here. The problem of
the SPARQL approach is that the whole intermediate document should be
expressed in RDF (no HTTP-in-RDF embedded in XML allowed).

So the best approach would be to use our own XML dialect with elements
and attributes "simulating" the ones in HTTP-in-RDF. I guess that I will
have to swallow my own words "recommending existing technology as
HTTP-in-RDF instead of defining our own XML dialect".

But if we use our own XML intermediate document we might be in a new
problem. If we are using EARL to express the results of our tests, we
might want to link one of the results to the test itself. That is, we
might want to relate a piece of EARL to a piece of our XML intermediate
document (i.d.). This would be easily made if our XML i.d. is completely
expressed in RDF.

There are alternatives as marking some parts of the XML document with
"id" attributes (not a very formal solution but it would work) so EARL
can easily deal with those XML pieces.

These kinds of things are the ones that made the ERT WG create
HTTP-in-RDF in order to relate test subjects to test results.

About translating RDFS into XSD, it seems as there is some research and
experimental stuff, but I guess that we would have to implement what we
want as it is all in paper. I will take a deeper look into Peter
Patel-Schneider's home page as he seems to be the guy to follow
(http://www.cs.bell-labs.com/cm/cs/who/pfps/). If someone wants to take
a look into his work, the "thread to follow" would be its paper "The
Yin/Yang Web: XML Syntax and RDF Semantics"
(http://www.cs.bell-labs.com/cm/cs/who/pfps/publications/yin-yang-www200
2.pdf).

If this is meant to easily convert HTTP-in-RDF into our XML i.d. (so we
do not start our XML i.d. schema from scratch) then I guess that it
would be faster to start the schema from a blank one instead of reading
all those papers and implement those ideas.

Best regards,

Nacho





-----Mensaje original-----
De: public-mobileok-checker-request@w3.org
[mailto:public-mobileok-checker-request@w3.org] En nombre de Sean Owen
Enviado el: jueves, 29 de marzo de 2007 22:41
Para: Jo Rabin
CC: public-mobileok-checker@w3.org
Asunto: Re: Sketch of documentation for mobileOK Basic implementation


On 3/29/07, Jo Rabin <jrabin@mtld.mobi> wrote:
>
> Hi Sean
>
> This is coming along nicely. Some comments:
>
> [a] afaik the jury is still out on how to actually run the tests. I
> think we should leave the architecture open and potentially run two
> parallel threads with the procedural team and the declarative team
> working in a competitive (albeit supportive, consensus driven and
> ultimately collaborative) way.

Two reference implementations? I'll be thankful if we can get one out.
I had thought the current design being discussed was about as
declarative as possible -- what more would you want to do here? at
some level there is going to be substantial procedural code and
there's no way around that.

> [b] we need to resolve what we are going to do about validity checking
> and the possible need to refer to external validity checkers

We will indeed have to make choices on libraries and run with them. I
think we have pretty good answers to all our needs in Java -- parsers
for XML and CSS, image libraries, etc.

Markup may be the most important validity check, and, I am favoring
relying on the results of parsing with an XML parser like Xerces
rather than the W3C validator library at the moment.

CSS, JPEG, GIF -- all important but I am basically content to rely on
whatever javax.imageio and the W3C CSS parser can do for us. I have a
feeling that their correctness is much more a problem in theory than
practice.

> [c] Tidy - as mentioned I prefer the idea of Tag Soup on the basis
that
> it seems to hold out the promise of having a declarative statement of
> what it is trying to do, plus Ruadhan has actually used it in the
> current version of ready.mobi

Tag Soup is fine by me.

> [d] I foresee the need to allow various configuration options and
thing
> there may be a need to refer to a config file to establish context
> [though I don't have a clear idea of what might be configured in such
a
> file at the moment]

This is where we may still diverge -- I think mobileOK Basic means one
thing, laid out by the tests document. If it's ambiguous, it needs to
be fixed. If it's not, then it's merely a question of implementing
what it unambiguously describes correctly. I don't see the situation
where you want to explicitly support multiple possible answers about
test results. It's true that the implementation may be buggy, but the
answer to that is a bug fix. Otherwise we have "mobileOK, but with
lenient mode turned on" and "mobileOK, but using Xerces 1.2" and so
on.

This is going to be open-source, and, anyone's free to build a
modified implementation from it or build their own from scratch, so,
there is always the possibility of divergent answers as to what is
mobileOK, some of which will be wrong. I am just pretty certain the
divergence will be negligible in practice, to the point this is not a
big problem.

Example: as you say the W3C markup validator seems to have some
glaring validation problems, but, it's still widely used and useful in
practice.

> [e] given that the intermediate results are likely to call on the
> HTTP-in-RDF  spec (which I confess I haven't had time to look at the
> latest version, having been immersed in mobileOK for the last few
days)
> is it appropriate to create a schema for our document formats. Is
there
> an easy way to turn an RDFS into an XSD for example?
>
> [f] similar ref results

Yes, um I confess I don't know much about this. I think we want a
schema for our new elements in both cases. Each document will also
include stuff from other namespaces like RDF and the HTTP-in-RDF
stuff.

Received on Friday, 30 March 2007 08:29:36 UTC