W3C home > Mailing lists > Public > public-xml-core-wg@w3.org > August 2009

Re: AssocSS issue 15

From: Simon Pieters <simonp@opera.com>
Date: Tue, 18 Aug 2009 11:25:31 +0200
To: "Grosso, Paul" <pgrosso@ptc.com>, public-xml-core-wg@w3.org
Message-ID: <op.uyupstgqidj3kv@simon-pieterss-macbook.local>
Without hearing any advice from Henry on how to proceed, I've gone ahead  
and produced a draft this morning based on the consensus documented in  


I have included requirements on documents (not relevant to xml-stylesheet  
processors) in order to make validators more useful for authors.

I have also included statements saying what the pseudo-attributes  
represent, however without giving any implementation requirements.

On Thu, 16 Jul 2009 17:22:26 +0200, Grosso, Paul <pgrosso@ptc.com> wrote:

>> OK, so in the _subsequent_ discussion, we were leaning towards
>> approaching this problem differently, by appeal to contextualisation
>> in terms of where this spec. sits in the picture of XML processor and
>> application provided by the XML spec. itself.
> And there was followup email discussing details of the wording.
> But back to the actual productions, my understanding is that our
> current plan is to have a production [1] (with only one right hand
> side) and a production [1a] something like what Henry shows above.
> However, to respond to Simon's issue about white space, I'm thinking
> we could do something like:
>      [1] StyleSheetPI ::= '<?xml-stylesheet' S PIBody '?>'
>      [1a] PIBody      ::= PseudoAtt (S PseudoAtt)* S?
> This does match a smaller set of PIs than before.  In particular
> <?xml-stylesheet?> used to match production [1] but would no longer
> match my suggested production [1], and <?xml-stylesheet ?> used to
> match production [1] and [1a] as Henry writes above but would no
> longer match my suggestion productions [1] and [1a].  On the other
> hand, neither of those PIs are syntactically valid xml-stylesheet PIs
> anyway because the href pseudo-attribute is #REQUIRED, so it doesn't
> bother me that they no longer are matched by productions [1] and [1a].

I've split the productions as above but without introducing subtle syntax  
changes. While it might not matter for xml-stylesheet, other  
specifications using the parsing rules might want to allow PIs with zero  

On Wed, 29 Jul 2009 16:01:52 +0200, Grosso, Paul <pgrosso@ptc.com> wrote:

> FWIW, while it's true the XML spec doesn't give details on how a
> PI is passed to the application, I note that the Infoset Rec at
> http://www.w3.org/TR/2004/REC-xml-infoset-20040204/#infoitem.pi
> says:
>  A processing instruction information item has the following properties:
>    1. [target] A string representing the target part of the
>       processing instruction (an XML name).
>    2. [content] A string representing the content of the processing
>       instruction, excluding the target and any white space immediately
>       following it. If there is no such content, the value of this
>       property will be an empty string.
> The way we're planning to define production [1a] below appears to make
> PIBody match the [content] infoitem.  This seems reasonable to me.

I've done this.

On Thu, 16 Jul 2009 18:39:23 +0200, Grosso, Paul <pgrosso@ptc.com> wrote:

>> This can be solved by using PseudoAtt? (S PseudoAtt)* S? (as I suggested
>> in the earlier email).
> I'm not sure.  If, when parsing, you skip PseudoAtt? because it is
> optional, then the next thing you must find is S.  I guess it depends
> how you read the BNF.  If you read this as DTD notation, I don't
> think this would work.  I'd think you need to say:
> PIBody ::= S |
>            PseudoAtt (S PseudoAtt)* S

I don't understand what the difference is between these two.

Simon Pieters
Opera Software
Received on Tuesday, 18 August 2009 09:26:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:40 UTC