The Vision Council

Administrators
  • Posts

    103
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by The Vision Council

  1. The ENGMARK question was resolved in email.  You can simplify this post greatly by removing all of that, or at least putting it into it's own topic.  This is quite a lot for someone to read and respond to.  If you can't simplify and shorten it I'm afraid you won't get much feedback.

  2. It's too small of a change to trigger a major revision in my opinion but this isn't my decision, it's the committee's decision upon which they have already voted.  This was not pegged for 4.0, which we have already started discussing.  I don't really have anything further to say on the subject myself as I'm just moving forward with the committee's decision.  You are free to vote against approval and present your case for why this deserves to be delayed until 4.0 to the committee when the draft is sent out for voting.

  3. Binary data is not limited to 80 chars.  In any event, this is really dragging out for what should be a very simple change.  We are simply trying to extend the max line length because some implementations are already doing so by necessity, which I believe is Mark's point.  The committee discussed this at two different meetings and voted on it.  Until now no one has said they felt this would be a protocol breaking change that would require a major revision.  Because the scope of the change was already discussed and voted on during the meeting, we will be moving forward with the new line lengths and limits as part of 3.13.  The new line length will be the sum of 16 characters for the record label, 1 character for the label separator, and 255 characters for whatever is on the right side of the label separator (no matter what we end up calling it).  Naturally, any other references that refer to maximum lengths of normal data (i.e. not binary data or some other data which already has an exception) will also be updated as necessary.

  4. 39 minutes ago, Yaron [LaserOp] said:

    Paul, just to verify, when you wrote here "field" length here did you mean "record" length?

    Or was that decided to be a "field" length limit, so a record with multiple fields could be longer (e.g. a chiral record would have max line length of 16+1+255+1+255) ?

    Good point.  I had originally referred to what turned out to be an imaginary "record value" in the pre-distribution draft.  I was told the correct term is actually field value but you're right.  Our goal is to limit the overall record length so we cannot set a limit on the "field value" itself.  We need a term that refers to everything after the label separator.  I'm proposing "record value" which is what I've used for years in my own documentation and code.  I was actually surprised it wasn't an official term when Robert pointed it out.

    In any event, I've sent that proposal to Robert so I'll work it into the draft.  We're still working on one or two other items anyway and this is an easy clarification.

     

  5. During the LPDS Committee meeting the working group presented their proposed implementation for concise base cure and range chart definitions.  This proposal is outlined in this thread:

    During discussions at the meeting representatives from Shamir pointed out that this method does not allow the specification of an allowable base curve range for a specific power combination.  The group requested this topic be started so further discussion could take place between now and our next meeting at Vision Expo West.