Re: Processing instructions for style tweaks?

Of course, we are agreeing about most things:  we agree that one should
generally separate basic information content from (especially "ad hoc")
presentation information, and yet we also agree that authors do need
some flexibility to specify formatting info sometimes.

> Subject: Re: Processing instructions for style tweaks?
> To: Paul Grosso <pbg@texcel.no>
> Date: Thu, 1 Dec 1994 16:32:15 -0500 (EST)
> From: Murray Maloney <murray@sco.com>
> 
> > From Paul Grosso <pbg@texcel.no>
> >
> > The advantage of using PIs for formatting-specific markup is that it's
> > easy to strip/ignore them when one wants to slough off the "pollution"
> > of embedded format-specific information.
> 
> But that is also true of attributes.  The advantage of attributes
> is that they can be parsed and verified as conforming by 
> an SGML parser and by an application, but the application
> can choose to ignore them.
> 
> . . .
> 
> So, what I was hoping is that we could define a few sets
> of attributes (attribute architectural forms) that could 
> be attached to elements to provide for formatting control
> at the element level. 
> . . .
> 

I don't think we're talking about quite the same thing.

Of course, if you have attributes that distinguish among your
classes of elements, you can assign different styles to the
different classes via your style sheets--and that's all architectural 
forms is doing.

I agree that's a good thing to do.  But I don't think that is
addressing the problem.  If it *is*, then fine, by all means,
let's add the necessary attributes to the DTD and be done with
it and forget about PIs, and I'm all behind you.  But that's
not what I'm hearing.

The problem I thought that needed a solution was the less
predictable "I need to do something different for *this* element,
and I don't already have something in my DTD that allows me to
distinguish this element from others (other than the ID method
which for whatever reason I'm not willing to use)."  Like, I
want *this paragraph* to have a different indent than all the
other types of paragraphs I have attributes/architectural forms for.

So, I need to be able--without changing the DTD!--to give this
paragraph some distinction that can be keyed in on by the style
sheet's "element class distinguisher" (aka the "location model"
or "qualified gi") so that I can, effectively, create a new class
of paragraphs (that will, perhaps, only have this one paragraph
in it) on the fly and then define the style I want for it using
the SAME style sheet language as all other style sheets.

> > With PIs, I can just strip everything of the form <?DL...>, or if my
> > software handles it, just say "write -nopi" and get a depolluted
> > version of the SGML.  And, if I send the SGML--PIs and all--to another
> > conforming SGML system that hasn't been programmed to do anything
> > special with <?DL...> PIs, 'no harm, no foul,' it just works and the
> > PIs are ignored.
> 
> Right.  And with attributes you can simply ignore them.
> Or you can ignore them selectively according to the 
> user's wishes -- as specified via a dialog.  No harm, no foul.
> The big difference is that you don't have to use a special
> filter or paser to ignore attributes, and you do have a 
> syntax that is verifiable by an SGML parser.
> > 

By definition, PIs are ignored by applications that don't understand them.
How much easier can you make ignoring them?

> > Finally, using formatting elements doesn't solve many of the problems
> > because they either can't be used everywhere one might want, or their
> > content models have to be so lax as to destroy the structure of the
> > original DTD.  PIs don't have to drastically change the ESIS tree of
> > the document.
> 
> I am not in favor of a proliferation of formatting tags.
> I am in favor of using attributes to associate formatting
> with an HTML/SGML element.

You already can use attributes to associate formatting with an element.
That's a basic part of DSSSL Lite (and FOSIs and other style sheets).
If you've got the attribute or can add it to your DTD, that is definitely
the way to go.  PIs should not be used to distinguish a structure that
can already be distinguished using information (elements and attributes)
in the DTD.  But, as I've said above, I'm hearing that this won't always do.

> 
> Finally, I have some practical issues with PIs.
> 
> -- We cannot define a DTD for PIs in an HTML document.
>    So, we'll have the same mess we had with HTML before
>    Dan started his effort to write a spec.  Nobody will
>    know for sure and there won't be any way to verify
>    it except for the "Mosaic test".  Heaven forfend!

I don't think this is quite true.  I suggested a format for PIs
in my other message that, if followed, would always make them "parsable."
The result would be a name (the PIs "gi") and optionally some
attribute specification.  If the name (or names of the attributes)
aren't to be found in the style sheet [by this I mean the result of
merging all style sheets for this doc], then nothing is done, and
this seems fine.  If the name is found, then how it affects the
format is specified in the style sheet using the exact same form
as for the style of DTD elements.

> 
> -- Placing PIs before and/or after elements will force 
>    applications to save formatting instructions until
>    the next element is encountered or to look ahead
>    in case there are formatting instructions coming.
> 
>    I am not a browser implementor, but I don't think 
>    that that is clean.  In fact, I think that it is 
>    unnecesarily complex and will discourage browser
>    developers from implementing this functionality. 

No!  If you use PIs like I'm suggesting, they just give you another
"handle" into the style sheet.  The formatting instructions come from
the style sheet just like for elements.  In fact, the application can
probably treat them exactly like elements as far as formatting.

> -- Forcing authors of HTML documents to learn another
>    language syntax to include their formatting hints
>    will discourage them from doing so.
> 

No, they don't have to learn something different--that's the point
of my suggestion.  The formatting attached to the PI is *in the
style sheet* and uses the *same* language as elements.

If you had a DTD element called <foo> that allowed you to markup
all bits of your document to which you wanted to associate the
style of "12pt serifed italic caps/small caps", you would mark
up you document using <foo>the appropriate text</foo> and you
would put an entry in your style sheet with qualified-gi=foo
and whose contents sets up the font as desired.  

Now, if you didn't have that element, but you had an <emphasis> element
with an attribute that could have 12 different values, you can mark up
your document using <emphasis specialclass=type8>the appropriate
text</emphasis> and you would put an entry in your style sheet with
qualified-gi=emphasis and whose constructor picked out those <emphasis>
elements with the specialclass attribute set to type8 and set up the
entry to indicate the necessary font.

But finally, if you've already used up all of those 12 values to map
to something else--or if the <emphasis> element wouldn't be allowed
in the context where you want to do this font change--then you could
mark up your document using <?DL foo>the appropriate text<?DL /foo>
and you would put an entry in your style sheet with qualified-pi=foo
and whose contents sets up the font as desired [in my example, I just
used "qualified-pi" instead of "qualified-gi" as earlier].  The style
sheet entry for the PI=foo and for the ELEMENT=foo would be IDENTICAL.

Received on Friday, 2 December 1994 17:51:49 UTC