• Please note: In an effort to ensure that all of our users feel welcome on our forums, we’ve updated our forum rules. You can review the updated rules here: http://forums.wolflair.com/showthread.php?t=5528.

    If a fellow Community member is not following the forum rules, please report the post by clicking the Report button (the red yield sign on the left) located on every post. This will notify the moderators directly. If you have any questions about these new rules, please contact support@wolflair.com.

    - The Lone Wolf Development Team

Questions: The Path Forward

Not an employee of Wolflair, but as a database developer... I would add this..

1. Is there an intention to add the ability to print any screen (topic/article) from within realmworks at some point?
2. Is there an intention to add a bulk import feature (spreadsheet, etc.) of some sort?
3. Is there any intention to release an API or open up mod support for features that are missing?
4. Is there any intention to include spellcheck?
5. Is there a "Hot List" anywhere that shows what features are being slotted for the future, etc?

1a. I think a report option could be added without too much difficulty to most database structures.
1b. I would like this but I don't think its a top tier issue but something on the wish list.
2. There are many applications out there that will convert documents into XML. I have played with this simply importing spreadsheets into Filemaker then exporting the XML structure. I have dabbled with local copies. It has not been pretty, but I haven't spent a lot of time doing it. I expect this could be done, but unless you had documentation from Wolflair, which I don't think they would need to spend time developing for public release given the nature of the product, it would be difficult.
3. API's can built for nearly anything. I don't see Wolflair going to the trouble to do this for numerous reasons. While I have not examined a local database I doubt Wolflair has any restrictions on access to the underlying database. Would I want to go in and write the classes and configurations for a those models? No thank you. But if you wanted it, I expect you could play with a local copy.
4. Spellcheck would be a nightmare as there are so many made up words, names etc. If I were the developer I would say set word up to learn your names, places, items and spells then cut and paste.
5. They have covered this on the website, I think last update was early 2016. Post Content Market Release I would like to see that list myself.
 
Last edited:
EightBitz said:
Maybe I misread it, but I thought kb's question was generally in regards to "Why would ANYONE pull data from CSVs when they can just export the CSV to an XML?"
Click to expand...

Yeah, he asked "How" not "why".

I see people looking at XML as some kind of magical format that, once data is in XML, everything is easy. That's a fairly naive view.

XML is a very flexible format for exchanging data between systems. Part of its value is that it is "self-describing", meaning that the XML file internally can tell you what kind of content is acceptable in a given record.

But what really makes XML shine for data exchange is having a DTD or XSD .. a definition of what is supposed to be in the XML data file. It specifies what records are required, which ones can appear more than once, what values they can have, and more. And those documents often represent agreement within an industry on a standard for data exchange... that's where XML becomes really valuable.

With a DTD or XSD (I forget the specific name DTD stands for, but XSD is "XML Schema Document"), programmers working on System A can write an export for data from System A, and programmers for any other system can write an import routine that can read that file and import it. If the XML document does not match what the DTD or XSD defines, it is "malformed" and will cause problems. The DTD or XSD can be used to "check" (validate) the document before attempting import and avoid having the import blow up in the middle of the attempt.

But the key here is that people ... programmers... still have to write both export and import routines that use that DTD or XSD as the guide. -- And, on this note, this is what is missing for data exchange between various VTT programs, or VTTs and other programs : an agreed-upon industry-standard definition of the data to exchange. (Not that it would be all that easy .. each Game System might well require a separate one because the underlying differences are too great.)

So exporting a spreadsheet (or anything else) to auto-generated XML as a file format isn't all that helpful. Because it is really just a heavily-annotated text file at that point. Someone would still have to do the steps you, EightBitz, are preforming ... pre-processing the raw XML into a form that matches the DTD or XSD.
 
Silveras said:
So exporting a spreadsheet (or anything else) to auto-generated XML as a file format isn't all that helpful. Because it is really just a heavily-annotated text file at that point. Someone would still have to do the steps you, EightBitz, are preforming ... pre-processing the raw XML into a form that matches the DTD or XSD.
Click to expand...

That is what I've been working on. I use a simple web site to convert a CSV into an XML file. The XML file merely has a row element inside of which are child elements. The name of each child element is the CSV "header".

I then use an XSLT to transform XML from that row/cell export format into the XML format required by RealmWorks.

This translation requires deciding where each of the CSV columns needs to be put into a RealmWorks topic. (This is the complicated step.)

The XSLT script generates another XML file which is in the RWEXPORT file format, so it can be directly imported into an existing realm.

----

Separately I have done a similar XSLT to convert the XML file used by the Obsidian Portal web site as a backup format, and remapped their fields into the appropriate fields for an RWEXPORT file.
 
Silveras said:
Yeah, he asked "How" not "why".

I see people looking at XML as some kind of magical format that, once data is in XML, everything is easy. That's a fairly naive view.

XML is a very flexible format for exchanging data between systems. Part of its value is that it is "self-describing", meaning that the XML file internally can tell you what kind of content is acceptable in a given record.

But what really makes XML shine for data exchange is having a DTD or XSD .. a definition of what is supposed to be in the XML data file. It specifies what records are required, which ones can appear more than once, what values they can have, and more. And those documents often represent agreement within an industry on a standard for data exchange... that's where XML becomes really valuable.

With a DTD or XSD (I forget the specific name DTD stands for, but XSD is "XML Schema Document"), programmers working on System A can write an export for data from System A, and programmers for any other system can write an import routine that can read that file and import it. If the XML document does not match what the DTD or XSD defines, it is "malformed" and will cause problems. The DTD or XSD can be used to "check" (validate) the document before attempting import and avoid having the import blow up in the middle of the attempt.

But the key here is that people ... programmers... still have to write both export and import routines that use that DTD or XSD as the guide. -- And, on this note, this is what is missing for data exchange between various VTT programs, or VTTs and other programs : an agreed-upon industry-standard definition of the data to exchange. (Not that it would be all that easy .. each Game System might well require a separate one because the underlying differences are too great.)

So exporting a spreadsheet (or anything else) to auto-generated XML as a file format isn't all that helpful. Because it is really just a heavily-annotated text file at that point. Someone would still have to do the steps you, EightBitz, are preforming ... pre-processing the raw XML into a form that matches the DTD or XSD.
Click to expand...
In case there was any doubt remaining, this!
 
kbs666 said:
In case there was any doubt remaining, this!
Click to expand...

You're missing the point. The point is not how a bulk import is made available; the point is there is not one so it has been left to users to mod a power-shell work around for something that is missing. Grant you, users who do stuff like this are worth their weight in gold; the emphasis is on the missing feature that really should be there.

For that matter, I would appreciate a clear channel of communication without having to search through a plethora of posts to find such details. o.O
 
Strategon said:
You're missing the point. The point is not how a bulk import is made available; the point is there is not one so it has been left to users to mod a power-shell work around for something that is missing. Grant you, users who do stuff like this are worth their weight in gold; the emphasis is on the missing feature that really should be there.

For that matter, I would appreciate a clear channel of communication without having to search through a plethora of posts to find such details. o.O
Click to expand...
You don't get it.

How would someone go about coding a bulk import feature? I've been writing software, specifically database oriented software, for more than 20 years and I have no idea how you could take in a random .csv and spit out a realm. The fact is, as Silveras already explained, the process we have now is the closest we are ever likely to get in regards to bulk import.

Right now with the right XLST you can transform a properly formatted spreadsheet into a rwexport file and import it. What more can you ask for?
 
Considering that printing was an extremely low priority, export to an external source was only going to be implemented if RW stopped development and import from an external source was never on the to-do list as far as I can remember, I think LWD has knocked it out of the park and bent over backwards for us. I'm still stunned and giddy about this.
 
I dint think it was for us as all �� I think the communities ability to turn around the bulk import as fast as it did probably surprised Rob as much as it did us. I also think we are all going to need to be a bit patient with what comes next. Our Realms have been isolated and safe up until now. What comes next can't be predicted 100%. There's going to be alot more data and alot more chance of bugs as a result of all the change we are capable of making. It's going to be really interesting. But this is why the content market isn't here yet. Rob is doing his best to predict what happens next and is focussing on destroying every bug before that happens. He's focussed on the foundation which none of us really take into consideration with our wants and needs. But honestly, what we all need is what Rob and team are delivering. A rock solid foundation to build our imaginations upon.
 
kbs666 said:
I could see wanting spell check specific to RW because I use a lot of made up words in RW. I add them to my spell check's dictionary but would rather keep them strictly in RW. But it is a fairly minor concern.
Click to expand...

Okay, that's a fair point. But with some text expanders, like Phrase Express, you can configure a trigger to only fire in certain applications. So you can still have application-specific spell-checking, managed by one application. But that does start to get fiddly. I certainly wouldn't mind spell-checking being available in RW, but it is very low on my wish list.
 
You must log in or register to reply here.
Back
Top