Reference and Include

[mzeftel]

We are looking at the Reference feature to improve it for the next release.

If you have any suggestions or requests for references or includes please send them to me, or post them here.

Thanks,

Mona

[MichaelMcCann,P]

Mona et al,
I agree with Al Pergande. I too decided that referencing wasn't much
help and the right hand page is the place to park such functions
before building them in as necessary. I now make all my Mathcad
documents self contained. I too found that I couldn't make the path
connections work properly and passing stuff over to clients made it worse.
I hope that the work is part of a plan to improve on MC14, not to
create a toy calculator to attach to a CAD drawing.
Mike.

[PhilipOakley]

I concur with all the points.
In response to one of Mike's point, why not allow the xmcdz (zipped/compressed) format be allowed to include the referenced files.

Many folk don't use Areas and Referenced files because they aren't a well integrated feature. But those that do persever do make maximum use.

The designers need to stand back and see them as part of a natural "whole" of a style of managing content [rather than "content management" = source control]

MathCAD is a leading edge product [i.e. used by folk who lead into the unknown], rather than just a high tech product(*) [used by those who automate the known].
(*) OK so there is a lot of that as well, but don't throw out the baby with the bath water...

Philip Oakley

[mzeftel]

We are designing included worksheets to be cached by default when the parent worksheet is saved, so the entire bundle can be emailed or shared with other users and work.

Only the regions that are needed in calculation, will be cached, so as not to bloat the files. Users will not be able to view or edit the cached files.

Let me know what you think.

You can also choose not to store the included worksheets.


Mona

[RichardJ]

On 12/29/2009 2:16:25 PM, Ted Diehl wrote:
>I am also concerned that
>companies that have main
>libraries will find this
>to break their libraries in
>that worksheets will become
>connected to "local
>copies" of the referenced
>docs. So when a "library
>owner" makes an upgrade
>to the functions in the
>library, they will not
>necessarily be read by
>everyone's worksheet under the
>concept you describe (If I
>understand it).

As long as it's a pure cache this shouldn't be a problem. So first it looks for the referenced sheet. If, and only if, it can't find it then it would use the data from the cache. This still leaves the danger that a user may think they are referencing an updated sheet even when they are not, so I would suggest that there is a warning when this happens, such as "referenced worksheet "xxxxxxx.xmcdz not found, used cached worksheet instead?".

In addition to the cache, it would be nice if we had a right click option for a referenced worksheet "embed referenced worksheet in current worksheet", which would convert everything to a collapsed area, with all regions (regardless of whether they are used for calculation, because some may be there as useful commentary) included. This latter option would actually be more useful in the context of emailing worksheets than a cache would be. Especially if the cache is missing all commentary and other non-calculating regions, and can't be viewed.

Richard

[RichardJ]

On 12/29/2009 2:16:25 PM, Ted Diehl wrote:
>Mona,
>
>I am concerned that this might
>not work with Kornucopia(r).

I would certainly think about the consequences in terms of IP. A user could easily, and unknowingly, distribute copyrighted material in the cache. To avoid this there must be a way to set an option in a protected worksheet "Do not include in reference caches". If the option is on then the worksheet can never be included in a reference cache, and, as per my suggestion in my other post, the user can not choose to embed it as a collapsed area either.

Richard

[RichardJ]

On 12/29/2009 5:33:17 PM, Ted Diehl wrote:
>Richard,
>
>Yes, I fully agree that we
>would need that type of IP
>protection for the
>person creating libraries of
>functionality. Beyond just my
>need with
>Kornucopia(r), many
>corporations would likely
>request this level of security
>protection.

It might even be a good idea to make that option the default, so someone at NSA (for example) won't inadvertently send all their decryption algorithms to their child's teacher when helping out with a homework assignment 🙂

Richard

[SteenGroðe]

I have some sheet that references to sheets on the net. These netbased sheet are protected as good as it gets in Mathcad, and I wonder how a new approach will have an influence on this.

Steen Gro�e

[pbaxter-disable]

On 12/29/2009 11:33:29 AM, Mona Zeftel wrote:
>We are designing included
>worksheets to be cached by
>default when the parent
>worksheet is saved, so the
>entire bundle can be emailed
>or shared with other users and
>work.
>
>Only the regions that are
>needed in calculation, will be
>cached, so as not to bloat the
>files. Users will not be able
>to view or edit the cached
>files.
>

Say I define "x" in sheet 1. Sheet 2 references sheet 1 but does not use "x" in any calculation. If sheet 3 references sheet 2, "x" is not available? Not sure I like that.

Why can't the VALUE of "x" be saved as part of sheet 2, and then be available in sheet 3? Currently all nested sheets have to be recalculated before the values can be used, which can take a long time and consume memory resources. Seems like an option of saving values would take care of this sometimes time-consuming recalculation process.

There would be similar issues with the parent file being out-of-date with the child, but some sort of "refresh references" could be incorporated to force recalculation only when desired.

Preston

[RichardJ]

On 12/30/2009 6:05:32 AM, Ted Diehl wrote:
>
>What does everyone think if
>Mathcad/Prime had the concept
>of a "Results
>Database" file? This SEPARATE
>file would store the results
>(what is
>essentially in memory,
>including the state of the
>"calculation tree") during
>the Mathcad calc. It would be
>a separate file from the
>current Mathcad files
>we are accustom to, so the
>Mathcad files .xmcd etc. would
>remain small. Many
>software packages that require
>long computations or large
>amounts of data
>use such structures (Abaqus
>FEA is one such example).

I suggested something like this years ago, although I would prefer the option of storing the results in the Mathcad file. I don't much care for having to keep track of multiple files.

What we have now seems to me to be the worst of all possible worlds.

Back in version 11 .mcd format results were not stored. So I could let a worksheet run for hours to do the calculations (I have a few that do in fact take hours to run), and if I closed it and reopened it I had to wait for hours all over again. The fact that it didn't store the calculation results had advantages though. First, if you save the worksheet it doesn't have to calculate everything. Second, you don't get file bloat due to the stored data.

Now what we have is a file format where it forces you to store the data! I can turn off the storage of large results, but not all storage. The thing is, although it stores the results, it then doesn't use them for anything! If I close and reopen the worksheet it calculates everything all over again! I believe the idea was that the stored results could be fished out of the XML, but how many people have ever actually done that? To add insult to injury, if automatic calculation is turned on (for me it almost always is) every time I save the file in xmcd or xmcdz format it forces a recalculation of the entire worksheet. I am actually currently working on a worksheet for which this takes so long I have to turn off automatic calculation every time I want to save it. It's a PITA!

What we need is the option of storing or not storing the results, and if we choose to store them it should also store the status of the calculations so that it only recalculates stuff if it is actually required. Perhaps we also need an option to store the results in the worksheet, or in an external file.

Richard

[PhilipOakley]

The ability to save the contents of the references
and includes into the worksheet is useful. [active
content as Mona described]

I have a colleague or two who have there own
"constants" file, and I'm always having to
recreate it.

The problems of IP do need careful consideration.

I have already suggested that there should be an
xmcdz option that includes all referenced (and
sub-referenced) files [complete content]. The key
point being that xmcdz is a GZIP compression and
could have those files included, with
encoding/password protection.

Password management is always an issue...

I also have the slightly complementary requirement
that the in the case of design handbooks, the
protection is open so as to allow full read (it's
our own IP) and ease of change (but with
detection).

The referenced files, no matter what method is
finally used MUST record and show the save date of
the stored content. The display format should be
easy to read and verify, and probably be in the
XML data for the file.

Just as design reviews will check that the correct
drawing number and issue is being reviewed, they
will also want to check the issue and save date of
reference

Philip Oakley

[RichardJ]

On 12/30/2009 5:56:39 PM, Philip Oakley wrote:
>I have already suggested that
>there should be an
>xmcdz option that includes all
>referenced (and
>sub-referenced) files
>[complete content]. The key
>point being that xmcdz is a
>GZIP compression and
>could have those files
>included, with
>encoding/password protection.

Encryption is not enough. You do not have the right to distribute copyrighted material without the owners permission, even if it is encrypted (and especially not if it can be used in some useful way even when it is encrypted).

Richard

[PhilipOakley]

On 12/30/2009 7:19:54 PM, Richard Jackson wrote:
>On 12/30/2009 5:56:39 PM, Philip Oakley
>wrote:
>>I have already suggested that
>>there should be an
>>xmcdz option that includes all
>>referenced (and
>>sub-referenced) files
>>[complete content]. The key
>>point being that xmcdz is a
>>GZIP compression and
>>could have those files
>>included, with
>>encoding/password protection.
>
>Encryption is not enough. You do not
>have the right to distribute copyrighted
>material without the owners permission,
>even if it is encrypted (and especially
>not if it can be used in some useful way
>even when it is encrypted).
>
>Richard

While that may be true, it is possible to simply copy the items to
the worksheet in many cases,

I think the particular case is where the referenced content is
itself IP protected. Even in the case of crypto protected, it
doesn't mean that it is a licence infringement. Thus it would
need an extra flag for the crypto that says 'no copying'.

some licences may expressly allow distribution, but be crypto
encoded....

good point though.

Philip Oakley

[pbaxter-disable]

The relative reference feature seems to work fine for me. We move files around on different servers and machines all the time and don't have to re-insert references.

Preston