Do I really need external references?

traveler_hauptman

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.

andrew_troup

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_hauptman

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_c

@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. 

3dcad

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?

traveler_hauptman

@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_hauptman

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_kumar

@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_hauptman

@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_hauptman

@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_troup

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_troup

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_troup

Deleted double post due to website stutter

traveler_hauptman

andrew_troup said:

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.