RE: Assoc SS issue list

Thanks, Daniel.

In several cases, I may not have represented your opinion
exactly, so feel free to correct me and/or bring up a
particular issue during the telcon discussion.

paul

> -----Original Message-----
> From: Daniel Veillard [mailto:veillard@redhat.com]
> Sent: Tuesday, 2009 June 30 6:02
> To: Grosso, Paul
> Cc: public-xml-core-wg@w3.org
> Subject: Re: Assoc SS issue list
> 
> On Mon, Jun 22, 2009 at 07:07:16PM -0400, Grosso, Paul 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.
> 
> 
>   Okay, for 1) if doesn't follow the xml-stylesheet syntax then it is
> ignored, so IMHO following questions are only about correct
> xml-stylesheet PIs in the document.
> 
> 2) Ignored per the spec
> 
> 3) if there is more than one correct xml-stylesheet PI in the prolog
>    for the same media value, I currently pick the first one and ignore
>    the others.
> 
>   => b) , that's what libxslt implements.
> 
>   e) makes no sense to me, the application got the full document by
>      default so of course they have access to all of them, the
question
>      is deciding how it could handle that conflict
> 
>  e) is compatible with any behaviour, so basically no guideline for
>  applications, and any behaviour would be fine. that's the status quo
I
>  though we were supposed to solve.
> 
>  If we don't care about the issue e)
>  If we care about the issue b)
> 
> 5) I don't test for duplicate attributes, I check only the ones which
>    interest me and very tolerant there.
>    g) makes sense to me but I don't implement it
> 
> 6) Hum, IMHO charrefs in PIs are a bad idea because users may be
> confused about where the expansion is done, assuming the parser handle
> them as for text. I would suggest to not use them, and note that
> URI escaping is the proper way , since basically that's the only field
> where non-ascii characters are likely to be found.
> 
>   Still if found and incorrect ignore the SSPI b) has my preference
> 
> 7) that's the case for example if the URI given doesn't parse,
> in that case I ignore the stylesheet PI i.e. f) but I won't look for
> other SSPI in the prolog for that media type, i.e. contrary to 3) it's
> ignored as the only value and the SSPI layer fail to find the href.
> 
> 8) text/xsl is accepted, b)
> 
> 9) no it's ignored, the XML character handling takes care of that,
> don't
>    mix layers a)
> 
> 10) I would say b)
> 
> 11) I validate against RFC 3986 b) i) and then ignore if failing 2)
> 
> 12) a) not within the scope of this spec
> 
> 13) a) Not within the scope of the AssocSS spec
> 
> 14) a) Not within the scope of the AssocSS spec
> 
> 15) I think c) is fine but it's true that the app doesn't see the
> markup
>     at that point so a) would make sense but I don't think it's a big
>     deal, I doubt implementors are confused by that, and users may
>     better understand seeign the full construct.
> 
> 
> Daniel
> 
> 
> --
> Daniel Veillard      | libxml Gnome XML XSLT toolkit
> http://xmlsoft.org/
> daniel@veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
> http://veillard.com/ | virtualization library  http://libvirt.org/

Received on Tuesday, 30 June 2009 14:28:22 UTC