Re: Assoc SS issue list

On Tue, 23 Jun 2009 01:07:16 +0200, Grosso, Paul <pgrosso@ptc.com> wrote:

> I had an action to produce an issues list for the Assoc SS spec,
> outlining what I thought were the potential resolutions.
>
> I have done that.  Please see
> http://www.w3.org/XML/Group/2009/06/assocss-issues.htm
> and feel free (in fact, please feel compelled) to email the
> list with your preferences, and I will add them to that document.
> Likewise if you want to suggest another potential resolution
> to be added to that document.
>
> If you are going to discuss an issue, please use the numbers
> to refer to issues and potential resolutions.

I agree with 1 and 2.

For 3, I think a..d are non-options, since we have to support multiple  
links for CSS:

    <?xml-stylesheet href="data:text/css,x { color:blue }"?>
    <?xml-stylesheet href="data:text/css,x { background:yellow }"?>
    <x>This text should be blue on yellow background.</x>

I agree with 4, although I would prefer MUST rather than SHOULD.

For 5, I prefer g.

For 6, I prefer b.

For 7, I prefer a.

For 8, I prefer b. (We should say that it's equivalent to  
'application/xml'.)

For 9, I prefer a.

For 10, I prefer b or c.iv. (We use MQ for CSS but ignore media=""  
altogether for XSLT.)

For 11, I prefer a or b.iv. (Note that b.1 is already covered in Web  
addresses.)

For 12, I don't mind a. (For CSS we would want to reflect updates, but for  
XSLT we ignore updates.)

For 13, I don't mind a.

For 14, I don't mind a.


Another issue that I've maybe forgot to mention: we should change  
production [1] to only include the processing instruction's *data* and not  
the leading "<?xml-stylesheet " or trailing "?>". Why? For two reasons:

   1. Allow reuse of the syntax for other specs (e.g. XBL2).
   2. An xml-stylesheet processor in reasonable implementations does not  
see the original character stream but instead a ProcessingInstruction  
object from the XML parser with a 'target' and a 'data'. (Actually when  
using DOM Core methods there is no character stream or XML parser involved  
at all.)

The production would instead be something like

    [1] PIData ::= PseudoAtt? (S PseudoAtt)* S?


Then we could also remove the check for "?>" in the value in production  
[3].

-- 
Simon Pieters
Opera Software

Received on Tuesday, 23 June 2009 11:03:06 UTC