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 17:53:35 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 
On 2019-07-27 00:29, Vadim Zeitlin wrote:
> On Sat, 27 Jul 2019 00:01:11 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> On 2019-07-25 22:53, Vadim Zeitlin wrote:
> [... "Old paragraph¶New paragraph" and "«bold:» not bold" ]
> GC> > GC> Alternatively, maybe we could use '_' and '||'' files.
[...]
> GC> >  You're basically proposing to use Markdown in policy files
> GC> 
> GC> Yes. But I still have some reservations about using ASCII.
[...]
>  Right, there are going to be corner cases with underscores and asterisks.
> But if we can afford diagnosing everything we don't understand (i.e. not
> matching underscores nor sequences of 3 or more underscores nor whatever
> other legal use of underscores could there be), they shouldn't be a problem
> in practice.

Current MST files contain multiple asterisks already:
    Substandard ***,
    Assumed Premium Allocation:**<br>
    *** This policy is classified as substandard guaranteed issue
If we tried to make "*emphatic*" mean "<em>emphatic</em>", we could
easily run into real problems, which could be ruled out by using
something more exotic.

But let's be clear about who sees such markup, whether it be

     '\n', "¶", or "||" or "{{paragraph}}" for <br>

     "_abc_", "«abc»", "「abc」", or "{{em}}abc{{/em}}" for <strong>

 - Kim and I maintain the proprietary product files, and the source
   code that generates them, so we're the ones who have to work with
   this markup, and no one else will ever see these files.
 - You wrote interpolate_string(), so to extend it, you'll need to
   know what markup we're using.
 - Customers, end users, and internal and external reviewers won't
   ever see any such markup.

so could you reimplement interpolate_string() to accept configurable
(single- or multiple-character, ASCII or multibyte) tokens, e.g.
  std::string const strong_open   = "<<";
  std::string const strong_close  = "<<";
  std::string const new_paragraph = "||";
so that Kim and I can experiment with alternatives and pick the one
we find most convenient (which could be hardcoded later)?

>  I'm even more sure we don't need the pilcrows because we can just use
> raw C++11 strings instead:
> 
>       std::string const s = R"(
>               This is one paragraph.
> 
>               And this is a separate paragraph.
>               )";
> 
> (and here spaces insignificance in HTML actually plays for us because we
> can indent the string in any way we want -- or not).

Interesting idea, but it's not going to work for us. Consider
the effect at various steps:
  (a) source code that generates '.policy' files
  (b) '.policy' files themselves
  (c) internal variables used to generate PDF output
  (d) PDF output files
Such indentation is erased (by HTML) before step (d). Step (c)
involves only transient data, where extra spaces can only be
seen with a debugger. In step (a), it might not seem to matter.
But step (b) involves physical files, where extra spaces matter.
Very often these days we're making changes in (a) that are
carefully designed to have no effect in (b), which makes
acceptance testing trivial; it wouldn't be trivial if (b) could
change in a way that would be equivalent but not identical. And
of course a GUI product editor operates on the (b) files, so it
would show all the superfluous whitespace.

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

That's an aesthetic shortcoming, but I'm not sure whether
it's of any practical importance.

> With partials, this interpolation will
> be done only when necessary inside interpolate_string() itself.
> 
> GC> If 'sample2xyz.policy' contains
> GC>   NameOfPolicy = "group insurance certificate";
> GC>   Footnote = "Read your {NameOfPolicy} carefully";
> GC> then that's already as simple as possible and as powerful as necessary.
> 
>  It's confusing though, as you never know whether you string is going to be
> interpolated or not and how many times.

Restating the example above because I failed to double the braces:
  NameOfPolicy = "group insurance certificate";
  Footnote = "Read your {{NameOfPolicy}} carefully";
After substitution, that needs to become:
  "Read your group insurance certificate carefully"
in which case it must have been interpolated exactly once, leaving
nothing further to interpolate. I don't see any confusion here.

Maybe you're thinking of recursive, multi-level interpolation:

  NameOfPolicy = "certificate";
  PolicyNumber = "12345";
  name_and_number = "{{NameOfPolicy}} number {{PolicyNumber}}";
  Footnote = "Read your {{name_and_number}} carefully";
  result: "Read your certificate number 12345 carefully"

The first non-comment line of interpolate_string() is
    if(100 <= recursion_level)
so it's already recursive. We've never cared about its actual
recursion level in the past, so why should we care about it now?

> GC> This
> GC>   Footnote = "Read your {<sample2xyz.policy:NameOfPolicy} carefully";
> GC> is verbose and redundant, and we'll absolutely never want anything like
> GC>   Footnote = "Read your {<SomeDifferentFile.policy:NameOfPolicy} 
> carefully";
> 
>  I don't think we need the name of the file here. In my "{{<policy:field}}"
> proposal, "policy" was literal and just denotes a namespace (whereas the
> implicit namespace is "file", i.e. in "{{<foo}}", "foo" is interpreted as a
> file name currently).

Data come from several sources (I think I enumerated four sources earlier).
But I see a datum's source as an irrelevant artifact that we already erase
anyway. For what purpose could it be useful to track its origin by adding
namespaces that we've never wanted in the past?

Or maybe you're thinking of using exactly two namespaces:
  {{<file:FileToBeIncluded.mst}}
  {{<all_other:NameOfSomeVariable}}
in order to overload '{{<'. That would add confusion IMO: the example above
would still be written the same way as always in an '.mst' file:
  NameOfPolicy = "group insurance certificate";
  Footnote = "Read your {{NameOfPolicy}} carefully";
  result: "Read your group insurance certificate carefully"
but if we moved that footnote into a '.policy' file, we'd have to change it:
  Footnote = "Read your {{<policy:NameOfPolicy}} carefully";
                          ^^^^^^^^ we'd need to add these characters
It would be simpler not to change it.

Maybe I'm missing something, because I perceive no advantage to using
partials or namespaces in '.policy' files.

> GC> > GC> Are we ready to proceed to the implementation details?
> GC> > 
> GC> >  There is still the question of whether to use Mustache partials or not.
> GC> > This, of course, affects only the use of MST in the .policy files, but 
> not
> GC> > HTML/markup, so if this has higher priority (as I guess it might), then 
> the
> GC> > answer to the question above is "yes".
> GC> 
> GC> Okay, we're ready to proceed.
> 
>  Note that if we don't use partials, we'll have to interpolate all the data
> coming out of the policy files. This is probably not the end of the world,
> but it does feel a bit strange to do it.

That's what I don't understand. To me, it seems perfectly natural,
obvious, and elegant.

Are you concerned about speed? Of course, I haven't measured it, but
it seems likely to me that the first pass or two will interpolate
just about everything, and if the "multi-level interpolation" example
above requires one additional pass, that additional pass should be
cheap, because there's only one "{{" left to find and deal with.
reply via email to
[Prev in Thread] Current Thread [Next in Thread]