lmi
[Top][All Lists]
Advanced
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Embed {{MST}} and <html> in product database

From: Greg Chicares
Subject: Re: [lmi] Embed {{MST}} and <html> in product database
Date: Sat, 27 Jul 2019 00:01:11 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 
On 2019-07-25 22:53, Vadim Zeitlin wrote:
> On Wed, 24 Jul 2019 18:10:26 +0000 Greg Chicares <address@hidden> wrote:

[...<ProductDescription> with something like ¶ embedded...]

> nobody thinks about the "product description" as 4 paragraphs of text, but
> rather as a single multi-paragraph text. So in this case I would be
> perfectly happy to just handle line breaks in the value intelligently and
> convert them either in "</p><p>" or, maybe, just "<br>" in HTML.

I don't know whether "<p>ABC</p><p>XYZ</p>" and "<p>ABC<br>XYZ</p>"
would render differently--but you probably do know, so I'll just
defer to your expert judgment here.

> GC> Alternatively, maybe we could use '_' and '||': i.e.,
> GC>   strong
> GC> which is in broad general usage already, and
> GC>   end of old paragraph||beginning of new paragraph
> GC> which is apparently what Sanskrit uses for a pilcrow. And this
> GC> "structural" markup could be translated in a distinct C++ function,
> GC> so we're never writing html markup in '.policy' files.
> 
>  You're basically proposing to use Markdown in policy files

Yes. But I still have some reservations about using ASCII.
Normal narrative text drafted by attorneys wouldn't include an
underscore, but we might encounter something like
  "Agent's signature: ________________"
which is sixteen underscores:
    ________________
, not fourteen boldface underscores:
  <b>______________</b>
or (if replacement is recursive) an empty septuply-bold string:
  <b><b><b><b><b><b><b></b></b></b></b></b></b></b>

But USA attorneys are never going to use guillemets, so
  «this is emphatic»
is unambiguous. And if <strong> is written with guillemets,
it's easier to detect whether it has been closed:
  ««this is emphatic»   Error: unclosed
  __this is emphatic_   Error, but harder to see

So now I'm thinking that guillemets and pilcrows might be better
after all. This silly sample does work:

diff --git a/product_data.cpp b/product_data.cpp
index f0507f32..b5f68202 100644
--- a/product_data.cpp
+++ b/product_data.cpp
@@ -566,7 +566,7 @@ sample2::sample2()
 {
     for(auto const& i : member_names())
         {
-        operator[](i) = '{' + i + '}';
+        operator[](i) = '{' + i + "¶ «etc.»}";
         }

(well, it will work as intended if we replace the special characters).

> [markdown] honours the
> explicit line breaks between paragraphs (while still soft-wrapping the
> paragraphs themselves)

I'm not sure how we'd represent that in the C++ source code that
generates product files, because
  std::string const s =
    "This is one paragraph."
    " And this is a separate paragraph";
is preprocessed to
    "This is one paragraph. And this is a separate paragraph"
so I think we still need something like ¶.

[...variable substitutions like "This illustrates your {{NameOfPolicy}}"...]

> GC> >  It looks like we should use Mustache partials for this: they're exactly
> GC> > what is used for including strings in Mustache syntax from elsewhere. 
> But
> GC> > this would make sense only if the string came from the policy file
> GC> > directly, we could then (easily) implement something like 
> {{<policy:field}}
> GC> > to get it from there and expand.
> GC> 
> GC> Such is not the case. Recall that product parameters are embodied
> GC> principally in two types of files:
> GC>  - '.database': numeric data
> GC>  - '.policy': string data
> 
>  Just to be clear, I only suggested using partials for .policy files fields
> and even then only for those for which it's necessary to do it. I.e. for
> simple fields, not requiring Mustache interpolation of their contents, we'd
> still continue to use just {{field}} syntax and {{<policy:field}} would be
> available in addition to it.
> 
>  Do you still object to doing it even so?

Yes, because I see no advantage to doing so. If 'sample2xyz.policy' contains
  NameOfPolicy = "group insurance certificate";
  Footnote = "Read your {NameOfPolicy} carefully";
then that's already as simple as possible and as powerful as necessary.
This
  Footnote = "Read your {<sample2xyz.policy:NameOfPolicy} carefully";
is verbose and redundant, and we'll absolutely never want anything like
  Footnote = "Read your {<SomeDifferentFile.policy:NameOfPolicy} carefully";

>  I really think we should go with the standard conventions (used by
> Markdown but really predating it for a couple of decades in common use) and
> use "_" and/or "*" for emphasis. And I think even some lawyers would be
> familiar with this use, unlike the use of "«" or "¶".

Let me emphasize that only Kim and I would ever see a pilcrow or guillemet,
and then only in '.policy' files and the source code that generates them.
OTOH, I haven't asked her yet, and she may find them inconvenient.

> GC> Are we ready to proceed to the implementation details?
> 
>  There is still the question of whether to use Mustache partials or not.
> This, of course, affects only the use of MST in the .policy files, but not
> HTML/markup, so if this has higher priority (as I guess it might), then the
> answer to the question above is "yes".

Okay, we're ready to proceed.

>  Moreover, I think this discussion could be rather short: let's just
> implement support for _very_ minimal Markdown subset right now. The only
> real question I have is about error checking/reporting: what would be the
> best way to deal with things like "This is _important, even if the closing
> underscore has been forgotten"? Worst would be to generate an unclosed <i>
> (or whatever) tag, but we won't do this. But should we ignore this lone
> underscore (i.e. drop it), preserver it verbatim, warn the user about it
> (but they don't control the .policy files contents, so what good would this
> warning do to them?) or try to fix it automatically (tempting, but
> potentially dangerous)?

Alternatively, use '«' and '»', and automatically diagnose anything
other than matched pairs, at the time the '.policy' files are
generated, or immediately thereafter. We don't need multiple degrees
of <strong>, so '«[^»]*«' can be treated as an error.
reply via email to
[Prev in Thread] Current Thread [Next in Thread]