Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.

First time visiting? Here are some places to start:
  1. Looking for a certain topic? Check out the categories filter or use Search (upper right).
  2. Need support? Ask a question to our Community Support category.
  3. Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
  4. Be respectful, on topic and if you see a problem, Flag it.

If you would like to contact our Community Manager personally, feel free to send a private message or an email.

Do I really need external references?

traveler_hauptmantraveler_hauptman Member, OS Professional, Mentor, Developers Posts: 419 PRO
10 months ago I wrote a list on my whiteboard of the features I need from Onshape before I'd start recommending it to my clients. Every new release I would check the new features against my list. Early on, Onshape ticked off a lot of things and by February all that was left was this.

For common parts libraries I figured the key ingredient would be references to external documents.This latest release has rolled out derived features but they are limited to same-document references. So they don't really fit what I'm waiting for.

However it has me thinking about the problems I'm trying to solve and how I'm using the tools Onshape is providing. One thing that is fun for me is that Onshape has reorganized how we interact with model information and it gives me an opportunity to reexamine my processes and workflows.

All a long winded intro to what I'm currently thinking about: where and why we need between document references.

For common parts libraries perhaps document tab copies are enough. I'll just create a document with tabs for each category of part and then cut and paste the tabs into my current document when I need one. I can use the derived part feature when I need to do in-context things.

Maybe I don't need between document references for part libraries.

But there are a couple situations where I need to propagate changes to the common library to documents that use it's parts.

The first situation is when updating a common part that someone (likely me) made a mistake with. If I notice a typo in the dimension of a common part, I need to get a list of all downstream documents that use that part and check them for problems as well as update their models. Being able to propagate the fix instead of manually re-entering it would be very useful.

The second situation is more important. If I add a new part to a library I've already pasted into my current document, that part is not going to be copied. The only way for me to get that new part is add another copy of the studio. My document get's messy with a bunch of tabs that are the same except for a part or two.

So I guess I do need between document external references after all.

Comments

  • andrew_troupandrew_troup Member, Mentor Posts: 1,584 ✭✭✭✭✭
    edited August 2015
    Is it fair to say that those references could be unidirectional?
    In other words, the updates could be driven entirely by, or "pushed" from, the source document?

    It seems to me that, provided the destination documents carry self-sufficient copies of the source item, and provided the source document "knows" the locations of all the destination documents (and the software permits the user to decide which ones to update), then Onshape could provide what you seek while continuing to avoid most of the 'evils' of the traditional situation where

    1) assemblies rely on being able to find all their parts in the correct places, with the correct names, and become unusable when they cannot

    2) it is possible (quite easy, in fact) to end up with the bi-directional reference situation where a part relies on references to an assembly AND the assembly relies on references to the part, from which no good thing ever comes... (not the same as the even more detestable circular reference, because bi-directional referencing does not necessarily result in a cascade of self-generated, spurious updates)

    3) Users readily and regularly become bamboozled by the web of interdependence, even if the software does not.
  • traveler_hauptmantraveler_hauptman Member, OS Professional, Mentor, Developers Posts: 419 PRO
    I think I'd leave the internals up to Onshape. The important thing for me is that things are DRY as possible and I can track or prevent propagation of changes in the situations where it would potentially break designs.
  • dave_cdave_c Onshape Employees Posts: 42
    @traveler_hauptman External references are actively being developed.  So rest assured it is coming.  It is a major architectural enhancement so it will take some time. 
  • 3dcad3dcad Member, OS Professional, Mentor Posts: 2,470 PRO
    One more thing to consider is shared documents and what happens to linked parts if you lose access to referenced document? This in mind I think andrew has pretty good idea how to keep things not braking apart..

    I'm thinking to give copy paste a real chance after we get parametric dimension so I can create different configurations of standard parts by only changing few parameters.. 

    I could probably live without external references if I could control parameters of those copies effectively. Meaning that if I find mistake in dimension, I just choose all the copies and set one time new value for certain parameter. 
    Haven't thought about this earlier, what do you guys think - would it be enough to get things going if we could push parameters instead of tabs?

    //rami
  • traveler_hauptmantraveler_hauptman Member, OS Professional, Mentor, Developers Posts: 419 PRO
    @dave_c Thanks for chiming in! Didn't mean to put you on the defensive; we know that it's in the works.

    Meanwhile, those of us downstream have to figure out how to get our jobs done, do it efficiently and decide whether Onshape is a good tool for that now, or at what point it will be a good tool.

    Never forget that all these posts with wild ideas, head-scratching, and weird workaround represent the extent of our knowledge and the ways that we will bastardize your beautiful creation as we use it. We will use your CD tray as a cup holder and your crescent wrench as a hammer.

    As a side note, I'd imagine keeping track of which body (part) is which is one of the things that makes external references difficult. In fact you might have it harder than file based CAD since any feature can affect all the bodies in a part studio and part studios typically have more bodies than traditional parts. I have no idea how far you guys are in the process but whatever fancy heuristic you use to track bodies as they merge and separate due to the features we create by intention or mistake, don't forget that the user is the ultimate judge of what their intent is.  Please make sure we can override any magic if the magic isn't working.

  • traveler_hauptmantraveler_hauptman Member, OS Professional, Mentor, Developers Posts: 419 PRO
    3dcad said:
    One more thing to consider is shared documents and what happens to linked parts if you lose access to referenced document?
    This is a really good question.

    I think this is easy technically but difficult socially. Technically you just say that sharing gives recipients permission for that version and don't delete that version (or document, whatever) until it has nothing using it. If storage is cheap, give each recipient a copy.

    Socially... what's my intention if I stop sharing a document with someone? And since IP could be involved, what happens if a court orders Onshape to stop one person accessing anothers model. It's conceivable that Onshape could be forced to break a large number of models if for instance a publicly shared and used library of parts had some models that were subject to a DRM takedown.

    (I have not done my legal homework to know if this is possible)


  • malay_kumarmalay_kumar Onshape Employees, Developers Posts: 93
    @traveler_hauptman I am curious why you think "keeping track of which body (part) is which" will be challenging with external references. I would think it will work the same way as it works with only references from same document and issues will be same with and without external references as far as tracking part is considered. Can you elaborate if you see any difference in keeping track of part with respect to external references as compared to within document references? 
  • traveler_hauptmantraveler_hauptman Member, OS Professional, Mentor, Developers Posts: 419 PRO
    @malay_kumar You are right. I didn't mean to imply that I think there is a difference. I think my statement (plea) above holds true in both cases. The user is the ultimate judge of what he wants.
  • traveler_hauptmantraveler_hauptman Member, OS Professional, Mentor, Developers Posts: 419 PRO
    @malay_kumar Of course your question (what's the difference between internal and external) get's me thinking. What's the holdup for external references. All just fun guessing. (dave_c's post suggests they are a long way away...)

    Let's say you have internal references as a solved problem. With external references you will want to refer to either a specific version or the head of a branch. Standard version control stuff there so I can't imagine that's holding you up.

    Permissions are currently per-document and that raises some issues. I may want to share a current version but keep new developments private. A while ago there was a lot of discussion in the forums about the need for per-version (or, at minimum per-branch) permissions. I vaguely remember Onshape participating in that discussion enough that we felt they got the message. I know I feel like this is something that's on Onshape's ToDo list.

    However your early release of external references could allow only references to document you own and you'd make a lot of people happy, so the permissions issue is probably not really holding you back.

    I guess on the UI side you don't have existing assets for selecting document+version+tab+element all in one go. Maybe that's the only thing?

    What did I miss?



  • andrew_troupandrew_troup Member, Mentor Posts: 1,584 ✭✭✭✭✭
    I think @traveler_hauptman raises a crucial point when he reminds us to distinguish what's difficult technically from what's difficult socially.

    External references are problematic to humans, because we do not, and can not, scan through everything we ever knew which bears on the problem at hand, every time we make decisions.
    We throw out documents or move them or rename them to meet an immediate need, which might be as trivial and myopic as making things look tidy and organised.

    Immediately this exposes a dilemma: we NEED things tidy and organised, because of our inherent inability to juggle many-layered complex multi-directionally interdependent systems. So it's not trivial, although it is (regrettably, but unavoidably) myopic.

    And that's why I think Onshape needs to be VERY careful how it responds to user push-back, when we try to add back in all the features we are used to having, and whose absence makes us (perhaps only temporarily) extremely uncomfortable.

    I would hate to see stuff put back in in response to the question "Well, Ok, why not?" 
    (with or without an implied shrug) 

    The questions "WHY?",
    and

    "If not that, then what?"

    should, I reckon, always trump "Why not" 
  • andrew_troupandrew_troup Member, Mentor Posts: 1,584 ✭✭✭✭✭
    Condensed summary of my last post for the TLDR non-reader, and/or the budding executive:

    If the status quo ante was so great, we wouldn't all be here.

    If we want to fix the admitted problems with the status quo ante by adding stuff to it, we've probably come to the wrong place.
  • andrew_troupandrew_troup Member, Mentor Posts: 1,584 ✭✭✭✭✭
    edited August 2015
    Deleted double post due to website stutter
  • traveler_hauptmantraveler_hauptman Member, OS Professional, Mentor, Developers Posts: 419 PRO

    If the status quo ante was so great, we wouldn't all be here.

    If we want to fix the admitted problems with the status quo ante by adding stuff to it, we've probably come to the wrong place.
    Nicely put.
Sign In or Register to comment.