Re: Processing instructions

Good laying out of the pro/con arguments overall...

On Tue, Jul 24, 2012 at 10:15 PM, James Clark <jjc@jclark.com> wrote:

> I suggest we keep each possible additional feature in its own thread:
> it will make our mail archives much more useful.
>
> On Wed, Jul 25, 2012 at 8:01 AM, Liam R E Quin <liam@w3.org> wrote:
> > On Tue, 2012-07-24 at 14:27 -0400, John Cowan wrote:
> >
> >> And given comments, you pretty much need PIs, or people will abuse
> comments
> >> for PI purposes.
> >
> > I'm not sure it's really an abuse, if you make a comment be the thing
> > that is asynchronous from the element tree and unconstrained in location
> > - think of it as a unification.
>
> I tend to agree.  I would hate to see PIs in content as a required
> part of the data model, but, if they are not part of the data model,
> then I don't see the necessity to keep them separate from comments. In
> my view the "right" way to do things is to use elements and attributes
> to encode machine-processable information; so I view PIs (at least
> those in content) as already an abuse.
>
> > But, losing xml-stylesheet and <?php?> might be too big a price.
>
> The <?php?> case doesn't bother me.  People use <?php?> to generate
> HTML all the time, but processing instructions aren't part of HTML5.
> All it means is that your PHP page that generates content type T isn't
> itself valid T. So what?
>
> I find <?xml-stylesheet?> case much more difficult.  I see arguments
> for and against.
>
> - Delivering XML to the client, which would be styled using
> stylesheets specified with xml-stylesheet, was very much part of the
> original XML vision. However, in reality the percentage of web sites
> that deliver content like this is vanishingly small. It's mostly a
> play thing for XML geeks.
>
> + I see MicroXML as being about making generic markup simple and easy.
> Using MicroXML together with an xml-stylesheet PI seems very much in
> keeping with this.
>
> - PIs are a significant complication to the syntax and the data model.
>
> + PIs at the document level can be made less disruptive to XML
> processing and the data model than PIs in content. (I'll expand on
> this in a separate message.)
>
> + PIs restricted to start-tag syntax makes them significantly less
> ugly in my view.
>
> - If we allow prefixes in start-tags, it's going to look very strange
> not allowing them in PIs.
>


I think this one is not at all a problem at all, but that's incidental
given my thoughts below.


- The HTTP Link header (defined in RFC 5988) provides an alternative
> to xml-stylesheet, which is arguably cleaner; the RFC defines a
> stylesheet rel.  Although browser support is not widespread, it is
> supported at least partially in the latest versions of Firefox and
> Opera: http://greenbytes.de/tech/tc/httplink/.
>

This is much more sound architecturally than ?xml-stylesheet?



> + The HTTP Link header won't work on local files.
>

A common problem with conventions that require out-of-band metadata such as
media types, but I think local file support is not an offset for the full
PI tax.



> Not sure what my conclusion is.
>

I'm starting to lean strongly towards the hard line of not allowing PIs. I
think much of their importance is historical, and the degree of added
complexity is quite a lot for gains of historical importance.


-- 
Uche Ogbuji                       http://uche.ogbuji.net
Weblog: http://copia.ogbuji.net
Poetry ed @TNB: http://www.thenervousbreakdown.com/author/uogbuji/
Founding Partner, Zepheira        http://zepheira.com
Linked-in: http://www.linkedin.com/in/ucheogbuji
Articles: http://uche.ogbuji.net/tech/publications/
Friendfeed: http://friendfeed.com/uche
Twitter: http://twitter.com/uogbuji
http://www.google.com/profiles/uche.ogbuji