Neil, again thank you for your time and suggestions.
On Sun, Aug 26, 2018 at 9:48 AM, Neil Van Dyke <n...@neilvandyke.org> wrote:
>
> Richard Parsons wrote on 08/26/2018 02:36 AM:
>
>> I actually think that free form text where the meaning was parsed through
>> its order might be quite nice. Something like: title, double new line,
>> date, new line, matter reference, new line, initials of author, double new
>> line, body of text, eof. It would of course mean that more work would be
>> required for each document parser and somehow it seems a little fragile to
>> me.
>>
>
> If you decided to try this, one thing that might mitigate it is to have
> visual indications in the editor for how these special parts of the
> document are interpreted by the system (like syntax coloring, tooltips, or
> inline callouts). That might actually be high-performance data entry.
>
> If you had many different such document-specific languages to code, you
> might see whether a DSL for specifying these languages helps implementation
> and maintainability.
I think that my staff would like this. In a sense, nothing could be easier
for them than to type a document as they normally would in a word processor
and have visual confirmation that they had correctly put the right bits in
the right places. I suppose I would probably initially setup with Scribble
syntax because it basically requires no work. I can just re-export the
existing scribble read-syntax function, selecting my own control character.
I could then add "markup-free" syntax later (which I think would literally
stun my work colleagues).
> Scribble syntax is definitely what I want for the records, so that they
>> can be embedded in the text: "Spoke to the client by telephone. Confirmed I
>> would @todo[#:deadline "2018-08-28"]{send out the court form} on Tuesday.
>> The client gave me his mobile number: @contact["client/mobile"]{01234
>> 567890}.
>>
>
> If your users find Scribble syntax hard to remember or hard to type, it's
> pretty easy to make a reader that uses fewer punctuation characters (and
> you could choose punctuation characters that can be typed without the Shift
> key on your locale's keyboards):
>
> "Spoke to the client by telephone. Confirmed I would [[todo
> deadline=2018-08-28 send out the court form]] on Tuesday."
>
> You could do all structural markup this way, or combine markup with
> inferred bits.
>
Yes, I do like that syntax and I think that they would find that easier.
Again, seems like a potential upgrade.
> Incidentally, your example is a good fit for how SGML (and then HTML) was
> intended to be used, for text markup using elements and attributes (but it
> does involve more typing, and SGML&HTML don't have TeX-like blank line
> paragraph separation):
>
> "Spoke to the client by telephone. Confirmed I would <TODO
> DEADLINE="2018-08-28">send out the court form</TODO> on Tuesday."
>
I don't know anything about SGML, although I have a general understanding
of HTML and XML. Are there Racket tools for SGML (a google search doesn't
immediately turn anything up)? One of the things that I like about the
Racket approach is that I can grow my languages: begin with the semantics
and then play with the syntax afterwards. I wonder if SGML would be
committing myself to a particular syntax or less flexible set of tools.
> On a separate note, all the users would need an understanding of what a
> "todo" markup in a document means (e.g., create a task in your separate
> task system, at the time that the document is processed, and leave the
> "todo" markup as-is in the document, like a traceability record, rather
> than edit the task in the document). And, as a developer, you have to
> decide what it means if the user can edit the "todo" in the document after
> it's already been processed and added to the task system.
>
Yes, my plan there was to use the existing Racket infrastructure. I would
write documentation and then the meaning of commands could be read on the
relevant web page and would pop up when people were working in DrRacket. I
would also introduce the markup commands one at a time so that my staff
weren't overwhelmed.
> (And maybe it should be called "task", or something other than "todo", if
> they use "todo" for notes about changes needed to the document-in-progress
> itself, and the document isn't complete until all the "todo" are gone.)
Agreed, "task" is better.
> If someone else wanted to use me as a domain expert and then develop it
>> closed source for them to market, then that is something that I would
>> consider.
>>
>
> In addition to closed source, there's been a number businesses that work
> on open source software as key developers, and their commercial value add
> is things like support, training, customization, and accountability. I
> suppose Red Hat is one to look at. (Ultimately, I prefer to let a good
> MBA-type figure out how to make the money.)
Yes, if anyone out there is like that then please let me know!
> For the purposes of my own business, I know what small steps we could take
>> immediately that would be useful based on the difficulties and limitations
>> of our existing workflow.
>>
>
> It sounds to me like you have a good understanding, and I like the idea of
> doing some of it incrementally.
>
Again, thanks for your helpful thoughts.
Richard
--
Redwood Legal
r...@redwoodlegal.co.uk
Office: 01157 323277
15 Clarendon Street, Nottingham, NG1 5HR
This firm is authorised and regulated by the Solicitors Regulation
Authority (SRA ID 637939)
--
You received this message because you are subscribed to the Google Groups
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
