All Activity

This stream auto-updates     

  1. Today
  2. Yesterday
  3. PROCBLK new record + SDFMODE extension

    In response to your three points: 1. We will be polling companies to determine the impact of relaxing the 80 character limit. The consensus at the meeting was similar to yours, that it is probably OK but we will need to check before making the change. 2. & 3. If I understood the committee's intentions correctly, all matching DEV would get A=2;2 and B=2;2. All matching DEV;VEN would get A=3;3 and B=2;2. My impression and belief is that inheritance was an expected benefit of this method. However, it may not be that everyone on the committee was thinking the same in that regard. I suppose we shall see based on this post. An interesting case to consider is that if for some reason you did not want your more specific DEV;VEN to get that overridden value you would have to do something like this: A=1;1 B=1;1 PROCBLK=1;DEV; 1!A=2;2 1!B=2;2 PROCBLK=2;DEV;VEN 2!A=3;3 2!B=1;1 That allows as much overriding and inheritance as one would prefer I think. Does anyone see any pitfalls with this approach? Or have I misinterpreted the inheritance discussions?
  4. Last week
  5. PROCBLK new record + SDFMODE extension

    Actually 3 more comments. All of these are also relevant to original PROC, which entered without dealing with them, so probably don't justify delaying adding PROCBLK to the standard if there isn't a quick agreement on them: 1. Record length. If any record can reach the 80 characters limit, then PROC (and prefixed records in PROCBLK section) carrying the same data would overrun that limit. And these records must be able to carry the same data, so by definition can overrun the limit. There aren't any really good options beyond dropping the limit altogether, which I personally suspect is fine (probaby nobody reads the data on fixed-length terminal screens, which I assume was the original reason), but it seems somewhat out of scope to just happen as an implicit byproduct of adding PROC+ without further discussion. 2. What is the handling of non-singular records? That is, of course there is only one LIND so if there is a better-fitting one in PROC+ it takes precedence. But what if a label makes sense multiple times, like for example if someone sends ENGMARK inside a PROCBLK? Should these replace ENGMARK (and such) records in lower-fit (or general) areas? Be added to them always and never replace them? Should there be a further modifcation to the structure to have a way to indicate this explicitly, since both could make sense depending on the individual case? 3. If something is defined/replaced in a lower-fitting area, and then not mentioned in an existing higher fitting one, should they be taken from general area or the best-existing area? I expect the intent is the latter, but without it being explicitly stated in the standard it's entirely possible for an LMS to decide to only consider the general and best-fit areas and ignore interim ones. To clarify, if that was too unspecific, imagine: A=1;1 B=1;1 PROCBLK=1;DEV; 1!A=2;2 1!B=2;2 PROCBLK=2;DEV;VEN 2!A=3;3 For devices not of type DEV both labels are 1. For devices of type DEV by a vendor that isn't VEN, both are 2. For devices of type DEV from vendors VEN, it is clear that A is 3, but it is not explicitly clear that B is 2 and not 1. Should the logic be "try to find the best fit for each label", or should it be "find the best fit block for each device and only use that with the general/global labels"? Again, I'm pretty sure it's the first, but see how the second could seem like a reasonable interpretation, so whichever is true should be mentioned explicitly.
  6. PROCBLK new record + SDFMODE extension

    That works for me.
  7. PROCBLK new record + SDFMODE extension

    Unless you guys feel further need to discuss I’m reading a consensus here. If I’m understanding the discussion at this stage then I will move forward with adding the proposal the group agreed upon at the meeting to 3.12 as it seems there is further consensus here that the prefix method is “good enough”. Further comments can be collected as part of the review process for 3.12 if necessary. If someone feels that my conclusion is premature please let me know.
  8. PROCBLK new record + SDFMODE extension

    The "have all the details in every line" is indeed not different from PROC. And since the whole idea behind PROCBLK was to avoid listing all the details over and over per each label, and since the discussion wouldn't have gotten this far if there wasn't general agreement among members that it's a good idea... this one probably shouldn't be it, it's just a more complex way of saying "no, just using PROC is fine". Which, again, it's considered to not be. About the unique prefix/identifier or not, again I see the main benefit as the ability to not keep things in order. So if it seems like a good benefit then having a prefix/identifier and no order requirement is the way to go, otherwise not having a per-block identifier is probably better. Why I don't think having a per-block identifier, while still keeping order, is a good idea: Technically, for machines/devices/software processing the data it's entirely useless. This is additional field, and data, and processing complexity, that serve no technical purpose, since if the labels are ordered then it's already completely known without being listed. Regarding: That may be true, but... well, why would the support/technical people reading the lms files (or communication logs) using notepad instead of one of the very many better text editors that can provide syntax highlighting? There are even lots of fantastic free ones. And they make life much easier for a lot of reasons. I mean, using a copy from the example file provided by Steve, do you really have any difficulty locating PROCBLK here: Or, alternately, same topic, if the purpose of the identifier is only to be human-visible anyway, why not instead specify that any PROCBLK label must be preceded by a few REM ones? That would create a very distinct visible break all by itself, while adding no complexity/logic for any device having to parse the data: Easier for everyone, and a lot less work to implement. Regarding These all have to be ordered, though, not just in terms of what they relate to (e.g. this R is related to that TRCFMT ), but also on individual sequence (this R is immediately after that R which is immediately after that R...) . But these PROCBLK sections only has the first aspect (which since section/dataset they relate to), without having any care about internal order beyond that. Well, unless there's another dataset inside a block, but that one would need to be ordered anyway regardless of where it is, and is not related in order to other labels. Not using an identifier per bloc, justifies having these follow the block in order, since there isn't another way to do that first type of connection. But having an identifier means that this relation is already done, and doesn't have to be maintained further. At which point it's no different from any other label in the standard that can be anywhere, and not enforcing order is the common case on the standard, not the exception. So, again, I like the prefix/identifier idea and think it was a good suggestion, but I don't see the benefit if it isn't used to remove the order requirement. Whether the order requirement is a good idea, is a different topic. I like "no" as the answer, but am not sure there's a good enough reason to add the effort of identifiers for it. What I see as potential reasons/usage-cases for not forcing order is mainly that I'm not sure there is a benefit to force order, and so why force a limitation without good reason? There are two main not-entirely-haphazard ways to send this type of data (main common record pool, and per-case exceptions): By case/device. As in the current ordered examples, an entire section for the general/common pool, and individual sections per case. It makes sense for the device/program creating it if they order things logically per case, and is useful when reading it (by a person) caring more about "what should everything be for case/device X?" By record/label, as is currently done most of the time, and as in the previous/ordered case is done internally per each section. All LMATID are together, all GAX are together, and so on. It makes sense for the device/program creating it if they iterate over available labels, and is useful when reading it (by a person) if caring more about "what is going on with label X?" . I'm not at all sure that the second scenario is more common/important/useful than the previous one. It's just that I'm also not at all sure that the previous one is that much more common/important/useful than this one. But forcing order enforces the previous one, while not forcing order leaves the decision to whatever creates the data blocks (nothing prevents them from still listing everything in order per PROCBLK, they just don't have to if they think it will be better otherwise). The main reason I saw mentioned for forcing order relates to: While I don't think scrolling a few lines up to PROCBLK is a problem, it can be a noticeable increase in effort to then search for "PROCBLK=prefix" and go back (minor for someone used to taking advantage of text editor features like bookmarks and "go-to-previous-location", but a bigger hassle otherwise (due to either habits or using a limited viewing tool). On the other hand, while the above problem is entirely true if checking a single label (e.g. LMATID), it's not so much if caring about multiple labels anyway. Since the work (scrolling up, or search then go-back) it split among multiple labels. And so that real but small effort would quickly become relatively negligible. Also, as a person going over a file that has multiple PROCBLK sections, I won't start by searching for LMATID, I'd start by searching for PROCBLK. Because there can be more than 1 that affects a device. e.g. in: If I need to know what happened for FSG;OPT;PLR then the labels needed may be spread among general/common ones, block 4, and block 5, in that increasing order of priority. At which point sorting out, say, all of LMATID, GAX, LIND: I have a very easy time finding which one I care about, and I already know what index values I want and which I don't. And this is from a file where they're not in order. Actually I think that having the identifiers (e.g. look for 4 or 5) makes it easier than if everything was in a line. Once you know what "5" is, it's easier to keep parsing (visually) than repeated "FSG;OPT;PLR;", it's less visually condensed and information-heavy. Having these in order would make things a bit easier here, but isn't really that much of a difference.
  9. PROCBLK new record + SDFMODE extension

    I can remember of 2 benefits having the prefix: - It makes it easier to scroll down a DCS packet and visually differentiate the blocks (as opposed to being very cautious and try not to miss a PROCBLK record when several blocks are following one another). - It might ease the LDS 2 LMS support to have a block identifier (as opposed to finding it by looking the the specific device / vendor / model / SN). But honestly, as long as we can agree on a solution that allows us to have device-specific dataset records , I'll be 100% happy.
  10. Earlier
  11. PROCBLK new record + SDFMODE extension

    What would be the difference between this and just refactoring PROC to support data sets? I mean, other than requiring more characters ("PROC=" for every line) it would seem to be the same thing and to me is cleaner since it's in keeping with the existing record formats in the standard. We would simply need to indicate that PROC records for data sets must be contiguous. I'm not fan of that solution as I felt the prefix idea from the meeting was clean and very simple but if we're going to go with this sort of approach I would think just tweaking PROC would be a more homogeneous solution.
  12. PROCBLK new record + SDFMODE extension

    One difference is that it will allow for datasets. A common thread I've heard (outside the forum) is that it's a bit verbose for the task. I'd argue that computers will be able to quickly generate or consume the extra text, but that when a human has to examine the OMA data to determine, for example, why a particular device is receiving a given LMATID, it'd be much faster to search through that text for "LMATID" and run through the results and immediately determine which device-specific line applied. That's as opposed to finding a LMATID line with a particular prefix and move back up to find out what to what PROCBLK that line belongs and getting the device there. Now it may be that's not a use-case that's of great concern to folks, and to help determine if I'm imagining a problem, I've attached three examples LMS files that use the three main recommendations for PROCBLK (or lack of it). So, what's the LMATID for a FSG-OPT-VHZ in each of these files? ProcBlockUniquePrefix.txt DeviceSpecificPrefix.txt ProcBlockRequireContiguous.txt
  13. PROCBLK new record + SDFMODE extension

    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.
  14. PROCBLK new record + SDFMODE extension

    That's a good point, Yaron. I'm a little torn on this, as it's entirely true that we have a number of other datasets that are necessarily ordered and contiguous. TRCFMT RR= RR= There's value in following that schema. Though, I think there'd be something cleaner about using a special character to indicate belonging to a particular PROCBLK, and the '!' seems handy for this, as I'm not aware of it being in use. PROCBLK=FSG;SCH;HSC !LMATID=70;70 !ETC=1;2 Where there wouldn't have to be any restructuring of the contents of the block, as the line is otherwise correct. Looking, the pipe character is a reserved character, and doesn't currently have a definition when used in a name, so that might be a better alternative if we want to maintain absolute compatibility. One other thing that might combine the best of both worlds - we've been using the tag for PROCBLK to identify an upcoming block...what if we didn't use PROCBLK, but simply had the machine prefix on the tag. FSG;SCH;HSC|LMATID=70;70 FSG;SCH;HSC|ETC=1;2 Pros 1) These device-specific records don't have to be contiguous. 2) Ease of knowing which device a line is targeting. 3) Backwards compatible. Cons 1) More verbose.
  15. PROCBLK new record + SDFMODE extension

    You are as astute as always... I almost posted an pre-explanation of why we didn't just do away with the prefix altogether. There was a lengthy discussion about it and your summary of why we kept it is spot on. The convenience factor outweighed terseness. At least I feel that is a fair assessment of the result. For the alternate format you proposed, it seems less clean to me than what we ended up with at the meeting but I'll let others comment. The version above will be put into the 3.12 draft for comment as well. Also, related to 3.12, the SDFMODE/LDPATH proposal has been postponed until a future draft so further work can be done. A revised proposal will be forthcoming.
  16. PROCBLK new record + SDFMODE extension

    Paul, thank you for that, it's good to have followup. (And I think can be a good idea in general to maybe post all topics post-meeting, to give even the people who were involved time to think things through more than is possible during a live meeting). Generally this seems good, just a few thoughts: The big, and only, benefit I see with having a variable/dynamic prefix per block is the ability to ignore the ordering requirements, since then the records then don't really have to be contiguous, and it's obvious which in-block line belongs to which block. But if they have to be contiguous and follow the PROCBLK record, like other datasets, then the different numbers add complexity with no benefit. In such case a fixed prefix (e.g. "B!" or always "1!", or whatever) would do just as well since anyway there can only be one active block at a time (same reason for existing datasets none of the "following" labels bothers to identify the first one it relates to, they're already strictly related by the order). Adding complexity for a potentially useful feature (and reducing the amount of exceptions to the no-order rule) is very valid, but adding it and then explicitly not using it and its benefit... isn't so much. Maybe it can be better to avoid having a new element (and separator) add to the "record" type, and instead just add a label for block content that accepts as first two fields the block identifier (prefix currently) and original label name (e.g. instead of "1!LMATID=70;70" use "B=1;LMATID;70;70") ? That avoids the need for a special record element and separator type entirely (no need to touch the definition of a record), in exchange for just one other label. Same functionality, about same amount of effort to parse. Is the "there's a new element type in a record" change not a bigger one than adding one more label?
  17. PROCBLK new record + SDFMODE extension

    Yaron: I wanted to post this follow-up based on our discussions from the DCS meeting today so you'd have a chance to offer your thoughts. Your insight on this proposal was extremely valuable and helped the group avoid taking a wrong path, so thank you very much! To members of the group please feel free to correct me where I've gotten any details of the consensus wrong. The group agreed to essentially adopt a modified version of your prefix label proposal: PROCBLK=Prefix;DEV;[VEN];[MOD];[SN] Where "Prefix" is an integer value. Instead of using "=" as a delimiter for the prefix the group settled on "!" (not already in use, not reserved, unlikely to be strongly desired to be part of a real record label name). By using the prefix the PROCEND record is no longer needed (all [prefix]! records belong to that PROCBLK). Examples of this PROCBLK format that the group came up with during the meeting would look like this: PROCBLK=1;FSG;;; 1!LMATID=70;70 1!_SCSBRD=2.50;2.50 1!_SCSBCCA=0;180 1!GAX=0;0 PROCBLK=2;FSG;SCH;HSC; 2!LMATID=72;72 2!_SCSBRD=2.50;2.50 2!_SCSBCCA=0;180 2!GAX=0;0 The standard will require PROCBLK to precede any prefixed records and that the prefixed records be contiguous. This would be similar to the other dataset definitions. Do you see any issues with this solution?
  18. Special Groove Rimless OMA File

    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).
  19. Hi, The results from the Power Map Datasets (5.12) and the Design Deviation Datasets (5.14) depend on the way the values have been calculated: - according to the permanent engravings; or - after repositioning according to the design, avoiding the errors due to the error on the reference engraving positions. You will find in the attached file a proposal for providing the information (‘DBP’- Design Based Positioning - applied or not). Unfortunately, the best way to add such optional field for providing this information is not clear to me. See you at VEE! Christian DCS Proposal - PMF and DDF without and with Design Based Positioning correction 2018-3-12.pdf
  20. Hi, in the attached file, you will find a proposal for defining the PRP and lens frame position for backside engraved lenses. This is the expected step after the introduction of the reference coordinate systems for backside and frontside engraved lenses in the DCS 3.11 (5.2.2 and 5.2.3). Looking forwards to meeting you at VEE, Christian Laurent DCS Proposal - PRP and lens frame definition for backside engravings 2018-3-12.pdf
  21. VEE 2018 Agenda

    Thank you Paul
  22. VEE 2018 Agenda

    Thanks Paul
  23. VEE 2018 Agenda

    Thanks Paul
  24. Current Draft Document

    Here is the current draft of the DCS. Change tracking has been turned on in this document. DCS v3.12_NEW Working_5.docx
  25. VEE 2018 Agenda

    The agenda for the meeting at VEE 2018 has been posted here:
  26. VEE 2018 Agenda

    The agenda for the VEE 2018 meeting has been posted here:
  27. PROCBLK new record + SDFMODE extension

    I won't be in the DCS meeting, which is why I'm trying to be very clear and detailed about the comments, so all the points will be available for the people involved in the discussion. (plus, well, I think it's a very good idea in general to consider things in advance, without the time limit of a live meeting, and so it's unfortunate that it seems nobody but you raised any planned discussion point here in the forums before the meeting) Regarding PROCBLK, yes, I think it's well covered at this point. Thank you. On SDFMODE... almost. Yes, I think full URI should be in LDPATH. No, I don't think SDFMODE should be completely removed. Unless, that is, the decision in the meeting is that the LMS value is unused and should be deprecated. In that case, yes, I do think SDFMODE can be completely removed as well. The functionality of it... is not stating the protocol to access LDPATH, but rather the mode of operation with the surface data referred to by LDPATH (FILE: on Host copy LDPATH as is, on device read surface data from LDPATH. LMS: on Host read surface data from LDPATH and send inline, on device read surface data inline and disregard LDPATH) No, I disagree that this position is a change of the original design/intent for SDFMODE and LDPATH, and I disagree that SDFMODE was originally intended as a way indicate the "protocol" to use. I claim that this change (having full URI for surface data in LDPATH, regardless of where the data is coming from) is very much in accordance with the original intent and definition. - That third point (not an actionable item itself, but probably a valid consideration when deciding about the actionable items) may need some explaining. These are what I see as strong indications that putting full URI in LDPATH, while keeping the same FILE value (or removing altogether) in SDFMODE, is as per the original design, and that specifying protocol in SDFMODE isn't: SDFMODE currently has 4 possible types of values. Two of which (LMS, FILE) are very clearly defined. The other two have a lot of vague/open parts in their definition (which I assume you agree with, as it seems a part of the reason you wanted to improve things). So for figuring "original intent" the better defined parts should weigh more. The two better-defined values don't actually specify a "protocol". So SDFMODE can't have been intended to specify the protocol of LDPATH. FILE isn't a protocol. Notice that right now it can be used (and often used) for local Windows file system paths (NTFS, FAT, ... ), or for local Unix/Linux file system paths, or for network shares using samba/SMB protocol (which is pretty much assumed as built-in for Windows, but certainly isn't/wasn't for earlier Unix/Linux systems and would have required special handling from such computers, or other devices). So already there are several different protocols that can be used to access surface data from LDPATH, none of which are explicitly named. So current uses of SDFMODE+LDPATH are, at about 100% of them, taking protocol data from LDPATH. LMS also isn't a protocol for how to parse LDPATH either. For a device receiving it, it means LDPATH isn't used. For an LMS using it... it means that LDPATH still contains a file source data path, but without any data on how or what it is. While I didn't see the original version of the DCS where SDFMODE was added in, and I wasn't involved in the discussions prior, I feel very confident (but please correct me if I'm wrong) in assuming that LMS and FILE were the main (or even only at first) values that the VC committee wanted to include, and the ftp/http mentions were added later or as a rough afterthought for "just in case we'll need something like that in the future". When sending data LDS->LMS it's possible (as per current definition of these labels) that SDFMODE will be LMS and then LDPATH will still contain a URI to the file path (in fact it's practically required). The Host is required to get the surface data from LDPATH, even though SDFMODE doesn't specify any "protocol". So the intent *can't* coherently be for the protocol to be in SDFMODE. The Host reading surface data from LDPATH (when SDFMODE=LMS) needs *exactly* the same info that a device needs to read surface data from LDPATH (when SDFMODE is something else), they're doing the exact same thing at that point. But for the Host... SDFMODE is already used. e.g. If on LDS->LMS communication SDFMODE=LMS, then it's possible that LDPATH=\\server\share\file.sdf , or that LDPATH=/mnt/somwhere/file.sdf or LDPATH=c:\folder\file.sdf . Without the FILE value being anywhere. But what if a new/future LDS will *still* want the Host to forward the data as in SDFMODE=LMS, but will share it files with the LMS/Host through an ftp server? It *can't* send both SDFMODE=LMS *and* at the same time SDFMODE=ftp://... . So it must send SDFMODE=LMS, and then LDPATH=ftp://... . Unless you're suggesting to either A) add another label, so there will be one for the LMS/host forwarding mode (how LDPATH could be used now, according to the definition, with FILE/LMS) and another for the protocol used by LDPATH . Or B) Remove the LMS value from SDFMODE while expanding it for protocols. None of these matches the claim that SDFMODE was originally intended to be used for protocol of LDPATH, since one of these is absolutely *required* to send "protocol" outside of LDPATH while still keeping other original value (LMS) usable. As mentioned before, LDPATH is already defined as can contain a fully qualified path. Which is a term that covers several types of a complete/full URI. So obviously LDPATH can contain a full URI, protocol signifiers included, as currently defined. So, I don't see any problems with original intent with just removing the current ftp/http options from LDPATH (or dropping it if LMS isn't needed) and only using LDPATH for surface source reference. The changes needed are pretty small, consisting of: Changing LDPATH definition to state "URI" instead of "path" (with matching syntax/phrasing changes) Adding a comment that actual supported protocols/formats will be dependent on agreements-with/support-by devices. This is the status today *already*, considering samba network shares aren't 100% supported out-of-the-box on everything already, and different O/S on devices will need file paths in a different format anyway. So that's not really a change but rather an already implicit assumption that isn't written in the DCS even though it should be. And it's about similar to what will need to be added anyway, just to SDFMODE on your original suggestion. That's simplifying things, and (as I hope I managed to express) keeping with original intent. It's also a change that "automatically" makes things future-compatible for future protocols, since it removes the current explicit mention of just several protocol, without explicitly mentioning any new ones.
  28. PROCBLK new record + SDFMODE extension

    Greetings Yaron, and again, thank you for your time! Interesting comments. Ok for the PROCBLK, I keep your suggestion in mind, let's discuss this during the DCS meeting next week. Regarding the SDFMODE, if I understand correctly what you are saying, you'd rather see this record completely removed and replaced with a full URI in LDPATH. The suggestion here was trying to stick to the original design (SDFMODE telling which protocol to use, LDPATH hosting the surface identifier). But this seems to be a valid option, and I propose that we discuss it next week, too.
  29. PROCBLK new record + SDFMODE extension

    Just as a quick addition, since you explicitly mentioned example of username/password which I didn't explicitly responded to: This is the same as any other type of data, except that one *does* have to be configured on the machine. But usage is the same, there is no benefit to splitting the URI between LDPATH and SDFMODE. Imagine, again, an ftp (or http, same format) URI. Option 1, splitting: SDFMODE=ftp://server:port/folder LDPATH=123.sdf which the device needs to convert to ftp://username:password@server:port/folder/123.sdf . This is not different from getting LDPATH=ftp://server:port/folder/123.sdf and turning it into the exact same ftp://username:password@server:port/folder/123.sdf . Not only that, but notice that in this case, which is your own example of the need to split to a "static" part in SDFMODE, in fact the data in SDFMODE is not static. Because the device took "static" data of "ftp://server:port/folder" and changed it to "ftp://username:password@server:port/folder" . Calling that one "static" is not strictly or necessarily correct.
  1. Load more activity