Written by: Bryce Hooper, Application Engineer at DASI Solutions

In case you missed the earlier parts, check out Part 1 on Excel and Part 2 on Word.

To conclude the series on PDM and EC forms, we’ll discuss something that not everyone is familiar with and most aren’t quite sure what it does. XML, or the Extensible Markup Language, can be used to store data. What does XML do exactly? Well, according to the source for web standards, W3 Schools, XML does nothing. That’s right. It does nothing.  However, it does store and allows us to organize data. For example, we can look at my EC form.

This form in the end will look very similar to the forms used in the first and second installments of this blog series. But to start, we have this:

So what do we have here? Well, we can see with the starting tag that we have an EC form. Everything within that tag is data for that EC Form. Going down the line we find the same information that we had in the previous forms, just with a different look. It’s still readable, but it isn’t necessarily pretty. There are a few things to understand about this data.

According to W3schools.com:

• XML was designed to be read and understood by both machine and human.
• XML was designed to store and transport data.
• XML was designed to be self-descriptive

These things seem to make sense when we look at our data. Our tags aren’t difficult to read, they seem to be labeled to make sense. And clearly this is storing data. It even does so in a very small format. (This file is about 920 bytes, as opposed to a 26 kilobytes file in Word. Not a huge file either way, but the difference is still large.)

W3 Schools also goes on to mention that XML is designed to be a similar markup language as HTML. As we all should know, webpages are made of HTML and allow us to make nice looking forms and pages. There must be a way to combine the two… but we’ll get to that later.

It is important to know, that XML does not have any pre-defined tags.  The tags shown in my examples are made up by me, and are nothing you have to stick with.

With that in mind, we will continue by setting up the variables inside of PDM.

The block name for this file type is quite simple. It is just XML. Same for the file type. The Attribute names can get a little… tricky. The SOLIDWORKS help goes more into what is possible, but I will start here with what I have in this image. We’ve already looked at the structure of my XML document. We saw that an EC_Form tag encompasses the whole form. From there we have children tags. This is reflected in the Attribute name. We start at the root level, and add the child levels after a slash (“/”). For this case it is “EC_Form/EC_Old_Rev”. My example above also has some tags buried 3 levels deep. These will look similar to this “EC_Form/Signatures/EC_Approval_ENG”.

Note: We cannot have any spaces in the names of our attributes in XML. The spaces cause issues interpreting the files.

Since we have this mapped, we will need a base template before the data card will automatically enter our data.

What is important, is that we create any root tags so that their children tags and be given values and that we have our most important header tag.

With this little bit of information, PDM can write the rest.

So… this looks nothing like a form. We can’t present this to anyone. What more can we do?  Similar to HTML, which has CSS to stylize; XML has XSL. This is the eXtensible Stylesheet Language. With this, and an additional tag, we can convince our XML document to look presentable.

Here we can write a little bit of HTML and CSS in an XSL format to help us display our data. My form isn’t too complicated, just a simple table and some formatting. I won’t go too in depth on how to write this as the focus on this is the XML as a form. However, I will provide my sample code.

This code, will result in a form that looks roughly like this:

Note that the values of the XML tags are displayed in this form through a special tag. This tag retrieves the value specified in the select statement. Now that we have a stylesheet defined, we need to tie it into our XML document. This is another easy tag across the top that looks like this:

The href tag is the path to the XSL file. In order for this to work, we either need to put this in a central location and reference it in an XML template, or copy it each time. For the best benefit of an XML form, I recommend putting it in a central location. My location is 2 levels above where my EC forms will reside, in the templates folder.

From here, we can take our standard approach to creating templates. Create a template card to capture inputs and fill in a serialized EC number. And, of course, we can create workflow actions to fill in values along the way.

As with any method, there are some pros and cons to this. As with the other methods I’ve discussed in this series, I’ll break down some of what I see.

Pros:

• Previews update without opening and re-saving the file
• Forms require no software beyond a web browser to be able to view or print
• Once a format is set, a change can be cascaded to all existing forms by altering the XSL*
• No known issues with variable types

Cons:

• Requires that someone know HTML/CSS to write
• Requires a folder structure to allow consistent reference paths if keeping the XSL in a central location
• Likely to be a new concept, so would require converting existing forms

*Changing the format of all existing forms can be avoided by creating a second stylesheet, leaving the first in place for old documents.

DASI Solutions

DASI Solutions is dedicated to service and support. As one of a handful of original, charter value-added resellers (VAR) in the SolidWorks Community, DASI Solutions has built partnerships and success stories with many of our customers. We are very pleased to bring you SolidWorks 3D CAD design engineering software and 3D printing services.