World: r3wp

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

Anyway I hope, you can use some of this input.

I don't see a difference between [ [] [[]] ] type nesting and what 
is currently used...I see that what you call "containers" are what 
the /  \  tags are doing.  Are you saying you prefer the scanner 
to die if the input is "illegal" than trying to proceed with it anyway?

what is there now already parses the "sketchy" usage in a reasonable 
way.

your examples do work pretty good on the new makedoc...just tried 
them in Developer IOS.

impressive.

MDP-GUI to be the interface for writing datas to Carl's blog script. 
does the idea sound usefull for you ?

like adding a publish or blog button to publish it directly to the 
web distant blog

I tried an earlier version of MDP-GUI but did not keep up with it. 
 I would like to try it to understand better its functionality.  
I think you have some good ideas there.

I use IOS to keep version control of my website...so I usually have 
things integrated with that...but the GUI could make it easier...does 
it run makedoc2.r as well?

yes I remember it but it was do to your low version that doesn't 
include teh set-face/clearface etc-face capability ...

oh yes, thanks, now I remember.

I'm trying to do somthing that allows you with a bunch of clicks 
to and some little tipping to make your full doc verry quickly with 
a lot of usefull functionnality like in true texte editors (I dont 
support yet direct texte rendering or color syntaxe) but there is 
some trully good advantages

on makedoc2.r   I can use * ** and *** bullets without trouble, but 
I don't yet understand the 3 levels of enum  should it be #>> or 
>>#  so far neither seem to work.

in the make-spec, there were things like ! and * for numbering ...