XML Library Developer Tool Problem in 9

[TomWaltz]

I had been experimenting with the Library Developer tool to convert GSM object files to XML files with the Archicad 8.1 library with great success in converting files.

In trying to use it on the Archicad 9 library, I am finding that the results are not as good.

To use it, I extracted Archicad Library 9.pla to a directory, Archicad9.lib/ I then ran the utility, LP_XMLConverter l2x <source> <dest>.

The utility seemed to be working, as files scrolled by in the terminal window. Upon completion, I found that the tool simply copied the GSM and raster files, but did not convert any of them to XML.

I am using LibDevTool_9_1810_Mac, on a Dual 2 GHz G5, running macOS 10.3.5.

Has anyone else gotten this to work in Archicad 9?

[Karl Ottenstein]

Hi Tom,

It works for me: scripts become xml, and images are just copied.

I'm glad you posted this as it gave me an excuse to try the tool out -- I'd been procrastinating.

I had been thinking of using it to change the default materials for a bunch of parts via a script, but I see now that it'll be tricky to do so. A material parameter looks like:

<Material Name="gs_frame_mat">
    <Description>
        <![CDATA[ "Frame Material"]]> 
    </Description>
    <Fix /> 
    <Flags>
        <ParFlg_Child /> 
    </Flags>
    <Value>15</Value> 
</Material>

So, if I want to change all "gs_frame_mat" in the window folder to 25 (for example) via a text editing script that isn't xml-aware, it'll be quite the regular expression to do the pattern match and substitution.

What have you been using the tool for?

Karl

[Aaron Bourgoin]

Dumb question #65

What does saving ArchiCAD objects in XML accomplish - what is its purpose?

[__archiben]

karl / tom

off topic but kind of related . . .

when the XML library converter generates GSM objects, how does it distinguish between the distinct parts of the script? can it be 'reverse engineered' by searching for some kind of regular expression in the GSM script?

please excuse me if i'm talking absolute nonsense here . .

~/archiben

[TomWaltz]

My goal is to convert the library to XML. Since this is a plain text format, you can do all kinds of cool things to it, like search and replace.

I want to put together a Perl script which uses regular expressions to search and replace values of parameters in the library parts to use our office's preferred defaults instead of the Graphisoft ones. This could be anything from "detailed" 2D display in doors to pen weights to materials.

It's tricky, as Karl mentioned, since the variable and the value are several lines apart, but I think I can pull it off. I've got the O'Reilly "Mastering Regular Expressions" and "Networking CD Bookshelf" which contains 5 books on Perl.

I may need to try it on a Windows machine to get the converter to work right. I've been using the 8.1 library to work on my scripts. The nice thing is that once I get the Perl part figured out, then it's just a matter of selecting all the variables I want to change, and looping the script to find them all.

Archiben: I'm not sure how familiar you are with XML, but it basically just uses the parts of the script as separate tags, An XML editor like Oxygen can tell them apart with no problem.

Once I get the script to work, I'd be more than happy to post it for others to play with.

[Karl Ottenstein]

TomWaltz wrote:
Once I get the script to work, I'd be more than happy to post it for others to play with.

Great! 😉

Just to add to Tom's answers...

To Aaron: besides global editing, as Tom mentioned, you can copy and paste entire blocks of parameters from one part to another. In GDL, there is no way to move parameters - they are defined graphically/interatively in the parameters screen of the GDL editor.

You can also imagine using a preprocessor, with #INCLUDE type behavior, to insert (and keep up-to-date) blocks of company-related parameters (for scheduling for example), common code sequences, etc... and much more. (Well, common params really belong in subtypes, but you get the idea.) Then, your "real" library is a meta-XML that is translated into the XML that the converter uses to produce a gsm library.

It makes sense that GS wrote this tool to allow themselves to manage the entire library ... and is great that they shared the tool with all of us. 😉

To Ben: as Tom said, XML tags separate each part of the script ... including the binary components - preview image and binary geometry. (Because binary data is converted to hex text, the size of an XML file for a binary GDL part is considerable: "Man Hands in Pockets" is 1.7MB in XML vs 788kb as gsm.)

At the risk of violating the license agreement, attached is the 19kb XML file for "Design Chair 05" if you want to see what the XML looks like. (Note that the gsm for this object is about the same size, 19kb.) You can open the file in Dreamweaver, Visual Studio, your browser, etc. to see a formatted view.

Karl

[TomWaltz]

Once I get the script to work, I'd be more than happy to post it for others to play with.

Although, any help with multi-line regular expressions working on text containing various brackets and quotes would be greatly appreciated!!

[Karl Ottenstein]

TomWaltz wrote:

Once I get the script to work, I'd be more than happy to post it for others to play with.

Although, any help with multi-line regular expressions working on text containing various brackets and quotes would be greatly appreciated!!

OK. 😉 I'm sure you know this, but in the general case, XML can't be parsed by RE because it allows for nesting, an LR(k) feature. (Any time you see a language with 'bracketing' operators - be they quotes, comment symbols, begin/end, <p>, </p>, etc., you know that a 'stack' is needed to count things and therefore it is not a 'regular language" [more formal definition relates to finite-state automata]).

But, the GDL XML pattern is specific enough that I think you can get a RE that will work adequately by taking sufficient context into account before going for the [.]* part (match everything up to the context of the param value).

Since you've already been debugging, you've no doubt encountered examples of where context matters, but here's a suggestion for making a lib part for debugging purposes to verify that your matching is working: if you have a parameter name that you're trying to match, place the same name in various other places, but including what you THINK is the matching context around it ... for example, the value of a string parameter variable, a string in the code, a comment in the code that actually looks like the entire XML block! Duplicate the XML param block in the Comment section of the library part. Etc. You'll see the problems that quotes (text strings), comment delimiters, etc. cause in trying to pattern match using just regular expressions.

To do a fail-safe job, you'd want to use lex/yacc/bison/etc (parser generator), since all context can be accounted for then. And, while I haven't looked, there must be a variety of XML parsers freely available which would be easier still. But, I think if you decide (reasonably) that the likelihood is extremely small that a piece of XML that looks like a parameter definition may appear in a context other than a param definition, that you'll be able to get get a satisfactory RE match.

Happy to help / test either here or offline, Tom.

Karl

[Andras Babos]

Hi Tom and Everyone,

I'd like to point out that although Perl is a rich language and Regular Expressions are fun to create (and a nightmare to maintain 🙂 ), it is probably not the language really suited for this task.

I think the correct tool to use in your case would be XSL. I'd suggest you take a look at http://www.w3schools.com/xsl/default.asp, and play around a bit with XSL on simple XML files. After you get the hang of it (it's quite easy I think) you should give it a try on your LibPart XMLs.

Basically you should have a template which matches the parameters you'd like to change, and a few other templates which match everything else (you'd not like to change). The latter templates would copy everything from the source, while the former could enact the change you desire.

You're going to need the Schema definition for the LibPart XML files, and it is provided in the Library Developer Kit (along with a more traditional DTD as well).

If you'd like to go along this route, I'll might be able to help you as I've been working with XSL for the past few months.

HTH:
Andras Babos.

[TomWaltz]

Andras

that sounds almost exactly what I'm looking for.

If I understand you correctly, though, I would have to determine everything I don't want to change, as well as everything I do.

Considering we are talking about thousands of objects, isn't that a tremendous amount of work? Or am I misunderstanding you?

-Tom