<div dir="ltr">I won't be making any changes for next week. Will work for the next deadline, if there's any.<div><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">behdad<br><a href="http://behdad.org/" target="_blank">http://behdad.org/</a></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 11, 2024 at 5:42 PM Skef Iterum via mpeg-otspec <<a href="mailto:mpeg-otspec@lists.aau.at">mpeg-otspec@lists.aau.at</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>

  
    
  
  <div>
    <p>I guess I can answer my own question here: You have your current<br>
      proposal document and we have newfeatvar_spec.pdf. If you want to<br>
      propose this change for the April working group meeting <i>cleanly</i>
      you can <br>
      do that by making an <i>additional</i> proposal <i>against</i>
      those two documents,<br>
      and emailing it here first. (newfeatvar_spec has all of the
      relevant VARC<br>
      content because of the editorial direction I took with it.)</p>
    <p>That would presumably propose to:</p>
    <ol>
      <li>Eliminate condition formats 2 and 4 from newfeatvar_spec.</li>
      <li>Change format 3 back to 2.</li>
      <li>Add the three additional formats.</li>
      <li>Note in the condition set section that that mechanism has been
        partially superseded</li>
      <li>Make the appropriate changes to 6.2.10.<br>
      </li>
    </ol>
    <p>This way the alternate system is genuinely severable from the<br>
      content that has already been discussed and approved as part of
      the<br>
      Ad Hoc process. <br>
    </p>
    <p>I've already indicated what some of the 6.2.10 changes would be,
      <br>
      but they are:</p>
    <ol>
      <li>The LookupCondition record now just has a conditionOffset and
        a<br>
        lookupIndexListOffset, from which lookups are taken when the <br>
        (now potentially compound) condition at that offset is true.</li>
      <li>Assuming we're eliminating the condition set, you'll need to
        note<br>
        somewhere appropriate that a 0 offset to a condition means the<br>
        condition is true (as is true of condition sets).<br>
      </li>
    </ol>
    I don't recommend getting rid of the conditionSet in the
    FeatureVariationRecord<br>
    because of the versioning issues that would introduce.
    <p>This still raises a lot of questions about lack of input and very
      short engineering<br>
      time, but it means that people could take it or leave it at the
      meeting on its <br>
      merits, rather than feeling pressured by it's sudden inclusion in
      a document<br>
      already tracked for approval. <br>
    </p>
    <p>Skef<br>
    </p>
    <div>On 4/11/24 16:09, Skef Iterum via
      mpeg-otspec wrote:<br>
    </div>
    <blockquote type="cite">
      
      <p>The current newfeatvar_spec document has the negated conditions
        and reorders the section on condition sets and conditions. This
        sort of addition would need coordination between the two
        documents. I'm on PTO Friday through Monday. How is this going
        to happen before the 17th?</p>
      <br>
    </blockquote>
  </div>

_______________________________________________<br>
mpeg-otspec mailing list<br>
<a href="mailto:mpeg-otspec@lists.aau.at" target="_blank">mpeg-otspec@lists.aau.at</a><br>
<a href="https://lists.aau.at/mailman/listinfo/mpeg-otspec" rel="noreferrer" target="_blank">https://lists.aau.at/mailman/listinfo/mpeg-otspec</a><br>
</blockquote></div>