[rfc-i] [IAB Trac] #266: Requirement for "Clear Printing"

Paul Kyzivat pkyzivat at alum.mit.edu
Fri Feb 15 14:21:22 PST 2013

On 2/15/13 4:59 PM, Marc Petit-Huguenin wrote:
> Hash: SHA256
> On 02/15/2013 01:48 PM, Paul Kyzivat wrote:
>> On 2/15/13 3:10 PM, Marc Petit-Huguenin wrote:
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>> On 02/15/2013 11:41 AM, Paul Kyzivat wrote:
>>>> On 2/15/13 2:10 PM, RJ Atkinson wrote:
>>>>> On 15  Feb 2013, at 13:23 , Paul Hoffman wrote:
>>>>>> Yes, it does, by keeping the column limitation to 72.
>>>>> I have no objection to including other formats with different column
>>>>> limits (or other formats with no column limit).
>>>>> A limitation that is specific to one of several possible formats
>>>>> (i.e. my proposal) is (by definition) NOT a limitation to the other
>>>>> possible formats.
>>>> Being required to provide a form of the ascii art limited to 72
>>>> columns imposes a severe limitation on the sorts of figures you can
>>>> use.
>>>> Increasing the limit to 90 columns would help a *little*.
>>>> Unfortunately there are lots of things I would like to put into drafts
>>>> that won't work with ascii art of any sort. (Right now I am looking at
>>>> a UML class diagram with 28 classes that have a lot of
>>>> interconnections. It *ought* to be in a draft, but it isn't going to be
>>>> in one any time soon.
>>> I wonder if a simple solution to that problem would not be to use a
>>> formal language representation in the input format and output text
>>> format, representation that can be automatically converted to a graphic
>>> for some formats, i.e, the txt format would keep the formal language and
>>> the HTML and PDF would have the graphic.
>>> Stéphane Bortzmeyer had a draft some time ago that defined a language
>>> for state machines[1], and provided tools to convert this to graphics[2].
>>> I am sure that other kinds of structured graphics (ladder diagrams,
>>> equations, class diagrams, etc...) can receive the same treatment.  As an
>>> implementer I would not mind using a text version that does not contain
>>> any ASCII art but only this kind of formal languages, as I would still
>>> have the possibility of rendering the graphics separately.  And formal
>>> languages are good for coding.
>>> This is in fact an extension of what we have today with ABNF.  The
>>> formal language is in the text format, but there is nothing that prevents
>>> the tool converting the xml file to PDF or HTML to generate syntax
>>> diagrams[3] instead of duplicating the text.
>> Its a plausible answer when its applicable.
>> In the case of UML, I'm not aware of any standard textual representation,
>> but there might be one. If so, its unlikely that it is very
>> human-friendly.
> http://www.omg.org/spec/HUTN/1.0/

This is starting to get off topic for this list, but to wrap it up:

I have spent all of 5 minutes looking at that, so take this with a grain 
of salt...

As best I can tell, the textual representation here is a way of 
describing collections of instances that conform to a particular UML 
model. It doesn't seem to have a way to describe a model itself, 
especially not a graphical rendering of a model. And a UML model without 
any hints about how to render it graphically is a huge challenge to 
render in a comprehensible way.

I'll be happy to find I have underestimated the state of the art - I 
haven't kept up with what has been going on with UML.


More information about the rfc-interest mailing list