Re: [I] Evaluate a ThoughtSpot TML converter [ossie]

["djwaldo (via GitHub)" <gi...@apache.org>]

djwaldo commented on issue #269:
URL: https://github.com/apache/ossie/issues/269#issuecomment-5577203923

   @utkarshparekh — the converter is up as #364, and I want to close the loop on what I said
   here, including one promise I have not kept in the form I made it.
   
   **On the mapping documents.** I said I would post the construct and expression mappings
   here for review. I have not, and I am not going to — but not because they were dropped.
   They were the design input for the converter, and now that the code implements the
   mapping, a separate document describing it is a second copy of the same facts that can
   drift from the implementation. So the PR instead generates its reference documentation
   *from* the code — the construct catalog, the reverse inventory, the datatype map and the
   vendor-payload key classification — with a test that compares the committed documents
   byte-for-byte against fresh generator output, so they cannot silently go stale. They are
   in `converters/thoughtspot/docs/`.
   
   **On the three licensing questions you raised**, which I think you were right to raise
   first: (1) the converter is built from publicly documented TML and independently written
   parsing — nothing derives from `thoughtspot_tml`; (2) every fixture is authored from
   scratch for this contribution, and they mirror `examples/tpcds_semantic_model.yaml` so the
   output is comparable with the other converters; (3) it went to `dev@` before code, and the
   one specification change it needed — adding `THOUGHTSPOT` to the `Dialect` enum — was
   raised separately and merged as #351.
   
   **On your v1 boundary.** The point you did not have visibility of, and which shaped the
   whole design: one Ossie semantic model corresponds to 1 + N TML documents, not one file,
   so the converter reads and writes the set. And ThoughtSpot formulas are model-scope while
   Ossie fields live inside a dataset, so every computed field needs an attribution decision
   — the converter attributes it to the dataset all its references resolve to, and refuses to
   guess when they span two.
   
   Your eyes on #364 would be genuinely welcome, particularly on the expression handling —
   that is the part where I made a judgement call you may disagree with. Details are in the
   PR description and the README.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@ossie.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org