World: r3wp

I have one...I think it was makespec.txt and on the world wide Reb...(through 
View Desktop) methinks.

Ok, I found "make-spec.txt". I'll use that as an example. Thanks!

I am always interested in input, so please let me know what you like, 
hate, etc.

wrt your comment on "hierarchical datamode

...there is a new way of grouping done in make-doc2

is it beyond the scope of makedoc2 to be able to create indexes from 
keywords?

I think, it's crucial to stick with the hierarchical datamodel, when 
making document formats.

Let's take bold and italic as an example:

This text is bold.

This is bold and italic.

This is just italic.

If we use the HTML tags and NOT sticking with the hierarchical datamodel, 
those examples could be done as:

<b>This text is bold.<i>This is bold and italic.</b>This is just 
italic.</i>

So not using the hierarchical model, we can end bold in the middle 
of doing italic text. That is confusing, because then we should be 
able to do the same with tables.

<table> bla bla bla <table> bla bla </table> bla </table>

That last thing is a table fully within another table. The first 
table is ended at the end, not where the first </table> tag is.

Back to the bold'n'italic example. It should be done this way:

<b>This text is bold.<i>This is bold and italic.</i></b><i>This is 
just italic.</i>

So if we stick with the hierarchical datamodel, it's a bad idea to 
use start- and end-tags, because it's then possible to do it wrong, 
and not sticking with the standard.

A better way is:

\b [This text is bold. \i [This is bold and italic.]] \i [This is 
just italic.]


When using a block, it's not possible to end something in the wrong 
place.

If I tried and wrote:

\b [This text is bold. \i [This is bold and italic.] This is just 
italic.]


The result would be, that the first and last text is bold, the middle 
is bold and italic. So "This is just italic." would actually be bold.

I maybe wouldn't get the result, that I wanted, so I had to change 
my text, but my text would be fully understood by the parser. This 
having start- and end-tags is a big problem with HTML, because people 
produce incorrect HTML code all the time, because it's possible. 
If HTML used some kind of a block structure in stead, a lot of incorrect 
code wouldn't exist, and it would be easier to make a browser.

RTF (Rich Text Format) seem to use the hierarchical datamodel too, 
but RTF solve the problem in an interesting way. My above example 
would in RTF be something like:


{\i0\b This text is bold. {\i This is bold and italic. {\b0 This 
is  just italic.}}}


\i0 means setting italic off, \i set it on. \b0 set bold off, \b 
set it on. A problem here seems to be, that you have to tell the 
condition of bold and italic for all text, and I don't like that.

what about alread mentioned open office format? Well, I expect it 
being rather complicated XML, but who knows ...

I mean - open document format ...

Steve - is make-doc2 downloadable anywhere?

One of the goals with the MakeDoc format is, that it's possible to 
easily read with a normal text window, and some people may want to 
edit it with a normal text editor and write the formatting chars 
themselves. XML is not suited for that. XML also has the same start- 
and end-tag problem (that I mentioned above) as HTML.

not the whole thing, just the parser ... but I have stuck it together 
various ways in Developer/IOS for experimentation and testing.

have you already looked into Robert's MDP? Back at the time of IOS 
Developers I used it extensively, including #include ... so I did 
script, which made doc out of many different sources ....

make-doc sorta chops up that problem, Geomol, in my way of thinking. 
 It gets para from newlines but sub formatting is possible...not 
sure if that answers your inquiries well enough

I have done some pretty strange experiments internally with it...will 
demo before too long, but having a blast.  I use several different 
customized make-docs for various things around here..

Do you use tags like \note, /note, \table and /table?

that is not a good thing, to have several incompatible variants imo 
... that is why there is make-doc project, which should produce make-doc3, 
open enough, allowing still the same level of easy of use, why otoh 
providing nicely formatted output ... I like what Chris did at Ross-gill.com, 
you can see output using two different .css files. Well, delete them 
and it will still work, even without .css!

If you do use those tags, I guess, this will be a problem:

\note A note

\table

some text

/note

more text

/table

ah, you misunderstood, Pekr.  make-doc2 is standard, but there will 
be thousands of products that developers create which utilize the 
standard core of it.

I like the things Chris and Robert have done to extend make-doc...and 
enabling different outputs from the same content is a very good thing. 
 no disagreement from me. (and make-doc2 is open source and very 
small, not so hard to work with.

(I used what you mentioned in the DevCon web pages, BTW)

Geomo: I think that is a problem anyway...to have a note criss-crossed 
with a table?  What would you want the outcome to look like?

Geomol....\group /group allows you to do some heterogeneous grouping...maybe 
to achieve what you want.

anyway, Petr...I didn't say "incompatible" ;-)

A note criss-crossed with a table; what should the outcome be? That's 
exactly the problem! A hierarchical standard based on start- and 
end-tags allow you to type it that way producing a problem. A hierarchical 
standard based on some type of container (block) makes sure, that 
you can't type something giving you a problem like that.

Example: note A note [table [some text] more text ]

Container blocks aren't pretty though, and don't give any hint at 
the end what they are closing.  The crossover you mention could be 
circumvented by a smarter outputter...

but we don't want to have to put that extra stuff into the simple 
text file (only what is absolutely necessary...and I agree with what 
Chris says.

think of the text as being entered in "paragraphs"

I THINK /group \group allows you to do what you want there, Geomol.

As I see it, I don't think you can apply the same rigour of a structured 
format to that of a free-form text format -- there simply has to 
be some level of user forgiveness, otherwise we need to create an 
even higher level format...

(though perhaps I see make-doc as higher level than it is/was intended)

It is entirely possible to parse blocks into text markup, when you 
want to allow code to automatically generate its own document (that 
is a hierarchical source, source code)

Geomol...your Example in make-doc2, now that you clarified:

\note A note

\group

\table

some text

/table

more text

/group

/note

###

Yes, it's possible! :-) It might also be possible without the group:

\note A note

\table

some text

/table

more text

/note

###


But my point is, that making the standard this way won't prevent 
the writer to type:

\note A note

\group

\table

some text

/note

more text

/group

/table

###


making an upredictable output. And that's the problem. It's not an 
optimal standard in my view.

A way to go may be to make a deep analyse of, what a document is 
- what it consist of. There are basic elements like letters, dividers 
(<br/>), ... Then there are bigger elements (containers) like notes, 
tables, ... And we can talk about change of state like bold-on, bold-off, 
italic-on, italic-off, font change, etc. The containers should be 
strictly hierarchical. The basic elements and the containers will 
be represented in a sequence. The inside of a container is maybe 
also a sequence. Decisions should be made, if change of state can 
happen anywhere, or if going to one state and back is a container 
too. (I'm thinking loud here, you may notice.)