Processing instructions

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.

- 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/.

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

Not sure what my conclusion is.

James

Received on Wednesday, 25 July 2012 04:16:44 UTC