[rfc-i] draft-iab-xml2rfc-02 - alignment of sourcecode

[pkyzivat at alum.mit.edu (Paul Kyzivat)]

On 2/2/16 12:18 PM, Paul Hoffman wrote:
> On 29 Jan 2016, at 10:46, Paul Kyzivat wrote:
>
>> The "align" attribute has been deprecated for <figure> while not
>> deprecated on <artwork>. But if your figure is contained in
>> <sourcecode>, what is the alternative? "align" isn't allowed there.
>>
>> At a minimum, "align" out to be allowed with <sourcecode>.
>
>  From a semantic point of view, why would you want to align source code
> other than "left"? What does center- or right-aligned source code mean?

How does it work for artwork?

I would want the entire block of source code aligned as a unit, 
left/center/right.

>> Also, I think left/center/right aren't sufficient alternatives for
>> alignment. At least historically I think these have been measured
>> relative the left and right of the *page*, without regard to margins
>> or current indent level. I would like to be able to align relative to
>> those.
>
> In XML, there is no concept of page margins.

This is info for the formatter, which may have a notion of margins.

>> For instance, consider ABNF source code. I would like the actual
>> content of the sourcecode to be valid ABNF. That means that the first
>> line of each rule must have no leading whitespace. So any indentation
>> needs to come from the "align" attribute. Generally I would probably
>> want to have the rules start out aligned with the current indent
>> level, or maybe a bit more.
>
> It sounds like you want "indent", not "align", but even then, I'm not
> clear why. The sourcecode for your ABNF can have spaces at the beginning
> of the lines, can't it?

If it is given spaces at the beginning of the lines then it ceases to be 
valid ABNF. (The first line of each rule cannot have leading white space.)

Currently people *do* put in white space so that it looks right. But 
then when the ABNF is extracted, the ABNF tools must themselves be 
modified away from true compliance with the ABNF syntax, so as to allow 
leading white space on rules. And that in turn is problematic, since 
distinguishing which lines start new rules is not well defined.

This will be a problem for any sourcecode syntax where leading white 
space is significant.

>> So it would be good to have additional possible values for "align" to
>> cover this, or another attribute (e.g. "indent" to specify the origin
>> to which "align" applies.
>
> For that to work, you would need to specify measurement units such as
> "spaces".

I'm just raising a general need. I'm not hung up on what the right 
solution is. Using indent "levels", or working relative to the indent 
level of the enclosing section might be possibilities. Using an 
attribute other than "align" would be fine with me.

Note that the "solution" of putting leading spaces on the sourcecode in 
order to match up with the indentation of the surrounding text has 
similar problems to specifying indentation in "spaces". (It won't be 
right for all different forms of formatting.)

Also, assume you get your figure/sourcecode/artwork all set so it works 
in your document. Then you restructure your document so it is within a 
section/list at a different nesting level.  It may not look right - you 
might need to insert extra "indent" spaces to get it to look right. 
Better not to need that.

>> Note that all these things also are relevant to line art. But with
>> line art there is less reason not to deal with it by including left
>> whitespace within the artwork.
>
> Line art is entered in the XML in <artwork>. Are you asking for an
> "indent" attribute there?

It is of lower priority to me, but I think a solution for sourcecode 
would be equally applicable to "line" art. It *might* also be relevant 
for SVG artwork.

	Thanks,
	Paul