Robert Shanbaum

  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Robert Shanbaum

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hi, Yaron, I apologize for being so tardy in replying. I'll go through your suggestions one-by-one. 1. I'm indifferent to the ordering of the revision history, but since it has been done newest first, it would take some work to revise it. Do you want to volunteer to do it, if the group approves of of doing it that way? 2. a) I also like "enumerated" better than "specified"; although it might be possible for only one literal value to be specified for a particular record's field value(s), in which case "enumerated" would be inappropriate. "Specified" is the more general of the two terms. However, we're splitting hairs here. "Enumerated" would be OK with me. b) We have always tried to enforce a measure of "terseness" in various text features. Just because a particular requirement can be relaxed when necessary doesn't mean that it's "effectively" a nullity. 3. Limited is there for a reason (namely, to limit the lengths of certain elements). My preference is to allow the constraint to be relaxed on an exception basis - if that's actually necessary. I don't recall why we added the "unless otherwise noted in the record definition." However, as I wrote earlier, I don't think that allowing an "override" eliminates its utility when it's not explicitly relaxed. 4. I'll ask Paul to fix the reference errors (he's still on board for that). 5. Same as (4), Paul will fix the revision history. 6. It was not my intention (or anyone else's, as far as I know) that this revision would change the location of an engraving. I agree that that is unacceptable.
  2. Hello, everyone. I hope you are safe and well. With any luck, you'll find a link on this message to a draft of the proposed version 3.13 of the Data Communications Standard. The first draft posted has a draft ID of 30; if any changes are made, and posted here, the draft ID will be incremented. Please download it, review it, and post any questions, comments, or objections on this forum, in this topic. I do not expect task force meetings to take place at the next Vision Expo West. We should try to discuss any issues that you may have with the draft on this forum; if it becomes necessary, we can arrange Zoom or GoToMeetings. I would like to be able to approve this version prior to our next meeting, which I expect to occur at Vision Expo East. DCS v3.13_DRAFT-030.pdf
  3. I think if the new requirements are respected - which includes limiting record label length to 16 characters - this is unlikely to be a problem. The problem situations that I've seen (where records exceed 80 characters) have generally been due to excessively long proprietary labels coming from LDS (for transmission, usually, to generators). I suspect that most LMSs have already dealt with this. The kinds of devices that might have issues with long records - I'm thinking of tracers and blockers - are unlikely to be receiving any such records in the first place.
  4. I suppose that it's possible that a use case could exist wherein a set of repeating records might need to be replaced by another set of repeating labels (or, possibly, just one label - an ENGMASK might replace a set of ENGMARKs, for instance). I'm not sure how likely such a case is to obtain.
  5. Yaron, we only send one tracing per packet, ever. And tracings are a special case, because I'm pretty sure that all LMSs can send whatever number-of-points or formats any device might specify in its initialization, without requiring PROC records (or PROCBLK datasets) at all. As I wrote, the standard is not presently explicit when it comes to which records (or datasets) might be repeating, but it seems to me that there's not really much doubt about which ones are, and which aren't. Can anyone name a record for which that is not true? I do not agree with the proposition that the presence of one record in a PROC record implies that another, different record should be changed.
  6. We didn't expressly address in the standard device-specific records that can appear multiple times; but as I wrote, I always figured these would be additive. It may be that we should expressly identify such records ("repeating records") - I can tell you that we have to do that in our software.
  7. It would appear that some elaboration of the definition of PROC records is called for. I think that my own interpretation has been that for records that can appear multiple times in a packet (such as ENGMARK or DRILLE) the operation of a PROC record would be to add the device-specific records to the records sent to the machine. We don't have a way to suppress sending particular records of that kind to a machine, but it's not clear to me that such a feature is necessary (and if it is, it will be challenging to implement in a robust way, requiring matching strings of characters across multiple "device versions" of a record). The more general case - wherein records are "singletons" (that is, only one record having a given label appears in any packet sent to a machine) - the usage is clear, is it not? I don't understand the comment above regarding a "non-optimal workaround"...
  8. But that last idea is not very different from a PROC record, is it? I suppose the presence of a semi-colon in a Record Label would suffice to identify the record as machine-specific. Given that PROCBLK was a form of shorthand for PROC records (and a reasonable way to handle PROC datasets), I don't think this would be a great approach.
  9. Tony is correct - there are very few requirements as to the sequencing of records in a packet out side of "datasets" (such as TRCFMT being followed by R records, and optionally, A, Z, ZA).
  10. Well - we can't describe a Panoptic seg either, or any number of features of various kinds of segments (radius of an Ultex?) .