Re: ACTION-516 [CTF] Evaluate how hard it would be to produce XML out of CSS stylesheets using SAC

I personally think that because we don't *need* a serialization in XML
as far as I can see, to complete the relatively simple CSS tests that
we have, that we should defer serialization for later consideration if
it becomes important.

I think we just need...
- a plain copy of the CSS doc in moki
- a SAC-based test implementation, not XSLT, that runs the MEASURES test

I personally am fine proceeding that way. I'd rather get something
working earlier, and I don't think implementing this harms later
efforts to do something else.

SEan

On 6/20/07, Abel Rionda <abel.rionda@fundacionctic.org> wrote:
>
>
> Hi folks,
>
> Miguel and I are working in our CSS action 515 -implement the CSS stuff
> (removing JXCSS, implement validation, and use SAC for test
> implementation)
> and we hope having some updates at the end of this week.
>
> A summary of these changes:
> *CSS grammar validation.
> *CSS information inside moki to fulfil stylesheet_support_test.
>
> With these changes we could take a decision on if this approach is the
> adequate or perhaps put our efforts in the serialization of CSS.
>
> One point that we are worried about is that the CSS tests are really few
> but they imply  modifications in moki in a very ad hoc way.
> (Having a serialization of CSS all the work would be in the XSLT side).
>
> So, it seems that we have a trade off between better maintenance (CSS
> Serialization) and rapid development (procedural approach) :(
>
>
> Abel.
>
>
>
> -----Mensaje original-----
> De: public-mobileok-checker-request@w3.org
> [mailto:public-mobileok-checker-request@w3.org] En nombre de Jo Rabin
> Enviado el: viernes, 15 de junio de 2007 22:50
> Para: Sean Owen
> CC: public-mobileok-checker
> Asunto: RE: ACTION-516 [CTF] Evaluate how hard it would be to produce
> XML out of CSS stylesheets using SAC
>
>
> I agree with the point about deferring till later what is not required
> now. However, we do need to parse CSS in some way, we do want to capture
> more than one error if there is one. And in addition to looking for
> absolute measures we also need to parse by @media rule and we also need
> to pull in @imports and also background and list images. All in all it's
> not completely trivial.
>
> So what I propose is that I get on with doing the minimal implementation
> per the above and extract some kind of structure with the relevant
> information in it. Whether that then goes on to being a full XML
> serialization I think is between me and my God and/or employer. It's not
> burningly urgent to have the XML serialization and there is a lot else
> to do.
>
> It does look as though the Flute parser is the one to go for, though the
> fact that it appears not to work correctly for CSS comments is a worry.
> If anyone has experience that goes beyond Batik and Flute that would be
> good to hear.
>
> Jo
>
> > -----Original Message-----
> > From: Sean Owen [mailto:srowen@google.com]
> > Sent: 15 June 2007 20:43
> > To: Jo Rabin
> > Cc: public-mobileok-checker
> > Subject: Re: ACTION-516 [CTF] Evaluate how hard it would be to produce
> XML
> > out of CSS stylesheets using SAC
> >
> > I don't have any problem with this sort of thing in principle --
> > merely concerned about the amount of effort it will take to conceive
> > and implement a new XML serialization of CSS. In fact, we need to do
> > very little with CSS stylesheets other than load and validate them. We
> > need to look for absolute units, which is almost an operation for mere
> > regular expressions.
> >
> > An XML serialization in the moki doc would no doubt be useful to
> > future generations of extenders. Any support for putting this off
> > until later though?
> >
> > I won't object if you really want to do it or anything but don't think
> > it's a must-have to finish an implementation.
> >
> > Sean
> >
> > On 6/15/07, Jo Rabin <jrabin@mtld.mobi> wrote:
> > >
> > > A status report on this action arising from our F2F in London this
> week.
> > >
> > > This comes from Dom's throw-away line "couldn't you just ..." and my
> > > taking the bait.
> > >
> > > So the story so far:
> > >
> > > I built a trivial framework around SAC and implemented a trivial
> > > ContentHandler and ErrorHandler.
> > >
> > > I used the Batik CSS Parser as the starting point - on the
> > > recommendation of the SAC Home Page [1] which says that it is
> smaller
> > > and faster than the W3C Flute implementation. It turns out that
> Batik
> > > appears to get into a tangle on the first error and doesn't appear
> to
> > > recover properly. So switching to the Flute implementation (slower,
> > > bigger) it does appear to recover from errors properly - and my
> guess
> > > would be that is why it is slower and bigger. But for our purposes,
> much
> > > more appropriate. Though time will tell actually how well it works,
> > > given that it appears not to pass through comments.
> > >
> > > (It's an interesting question, I suppose, that the Batik parser
> appears
> > > to contravene the spirit if not the letter of CSS parsing rules, and
> > > consequently, perhaps it should appear with that caveat on the SAC
> home
> > > page).
> > >
> > > So far as JXCSS is concerned, the implementation notes say that it
> > > doesn't work with Flute, if I remember correctly, which is a
> limitation,
> > > and it does not implement an error handler. Neither of these is a
> > > terminal error , I guess, but it does raise the question of whether
> to
> > > implement afresh - in reality copying much of what JXCSS does in its
> > > document handler, or whether it makes sense to carry out surgery on
> > > JXCSS itself and contribute it back.
> > >
> > > I think that given Sean's military attitude to coding style :-) we
> are
> > > probably better doing the former, with due acknowledgement, of
> course,
> > > to where code has been 'borrowed'.
> > >
> > > There's of course the issue of error messages ...
> > >
> > > ... so the conclusion seems to be that the answer is 'yes' - I am
> not
> > > going to be able to do much more work on this over the next week or
> so.
> > >
> > > Jo
> > >
> > > [1] http://www.w3.org/Style/CSS/SAC/
> > >
> > >
> > >
> > >
> > >
> > >
> > >
>
>
>

Received on Wednesday, 20 June 2007 14:36:57 UTC