I´m going to develop a gui to help the building of the resumé, but i fear that the project its not solid enought for me to trust in his future, and i dont want to use a schema that will be bloated in a few months/years. Can the authors or someone give me some advice of what to do ????
Jayme
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You certainly can't count on the XML Resume schema not changing for the next few years. There is already a beta release for the 2.0 version (although nothing has been done with it for quite some time), and I've heard that there are some changes waiting in the repository. Also, Matt LeClair is waiting to incorporate some of his own changes: https://sourceforge.net/mailarchive/forum.php?thread_id=10121224&forum_id=1138
Also, note that XML Resume is not the only resume format in town. There is also the HR-XML standard: http://cvsieve.sourceforge.net/
That said, may I offer a suggestion: Why not design your program in a modular way to make it future-proof? In other words, you could store all the data for the user's resume in your own custom format. You could then translate your custom format to and from any resume schema as needed. That way, if a schema changes, you only have to change the file translator, not your GUI. It would also allow you to support more than one resume format, not just the XML Resume type.
For example, you could store your GUI's data in a custom XML format, then write XSLTs to translate it into HR-XML and XML Resume formats.
By the way, will you be making this program open-source? I'd be interested in helping out.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2006-04-14
I'm not sure how necessary a gui will be in the age of schema-aware XML editors/IDEs. If you use something like XMLSpy (for PC) or its free software equivalent, you can see what element should come next as you type out the resume. You can also see all the attribute names and what possible values they may have. I think this will get easier with a proper schema as opposed to the current DTD. A schema is certainly a priority item.
I never tried ORC (online resume creator) before it was taken down, but I think this allowed the user to create their resume through a series of web forms. If that's true, I think it would be a good solution. After a series of forms, the user would be able to download their resume in xml format (and perhaps pdf/text/etc). If a java gui is prefered by some users, it ought to be driven off the xmlresume schema (if it wishes to be compatible with this project). I'm not adept enough at java to take this on, but I would assume that a java app could read an xml schema and prompt the user for the quantity of elements of a given type ("job") and then ask for all the values required to fill it in.
I perused the cvsieve subversion viewer and it looks like there is some XSLT code (like attribute-sets) that could be helpful for xmlresume. What I'd like to see if some way to mimic style sheets so more than one PDF output is possible. This is easy with HTML by using CSS, but with XSLT it's much more difficult. You have to use template modes and it's not easy for someone to just contribute a new PDF style as a new file ("joe's style.xsl"). I don't know what the solution is there except to keep expanding parameters.xsl and restructuring fo.xsl. But that gets cumbersome.
I'll have to look at cvsieve more and compare it to the hr-xsl project. It seems like they share code. Right now there are 3 seperate sourceforge projects all primarily aimed at converting XML resumes into text and PDF. I'll have to give it some thought, but somehow these ought to be merged or made compatible with XSLT translations.
Although we could try to convert xmlresume's element names to match hrxml, it might be best to convert hrxml into an intermediate format which allows us to add more elements (the full xmlresume dtd/xsd). Likewise, we could convert a subset of xmlresume to hrxml. The xmlresume dtd/xsd would be what is ultimately used for PDF/text/html/rtf generation. That's the only way we can respond to all this feedback asking for more features while still maintaining a consistent element-naming scheme and compatiblity with HRXML.
Vocaro, I wanted to mention to you that your sample resume.xml and resume.pdf featured on the cvsieve's main page do not open. I had to look at copies from within your subversion repository. Thanks for keeping up with all the recent posts on this forum!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"I'm not sure how necessary a gui will be in the age of schema-aware XML editors/IDEs."
I think it will be very necessary. XML editors tend to be general-purpose and thus rather complex. They can easily overwhelm the user with all kinds of features that may be completely irrelevant to someone who just wants to create a resume. In addition, such editors don't have any domain-specific features. For instance, a custom app for handling XML resumes could add additional features like uploading the resume to a job site, performing a mail merge, or any other resume-specific automation technique that a generic XML editor couldn't do. In short, I'd much rather work with a resume editor that understands XML, rather than an XML editor that doesn't understand resumes.
"l have to look at cvsieve more and compare it to the hr-xsl project. It seems like they share code."
CV Sieve is nothing more than a fork of HR-XSL. You can think of it as HR-XSL 0.4; it includes bug fixes and a few new features compared to 0.3.
"Right now there are 3 seperate sourceforge projects all primarily aimed at converting XML resumes into text and PDF."
You mean XML Resume, CV Sieve, and HR-XSL? I would only count the first two. The HR-XSL project seems to have died, and with the CV Sieve project I'm trying to pick up where HR-XSL left off.
"What I'd like to see if some way to mimic style sheets so more than one PDF output is possible. This is easy with HTML by using CSS, but with XSLT it's much more difficult."
Yes, I've had the same concern. This is why I added a LaTeX converter to CV Sieve. That way, you can tweak the LaTeX output, making it look exactly how you want, then convert to PDF.
"Although we could try to convert xmlresume's element names to match hrxml, it might be best to convert hrxml into an intermediate format which allows us to add more elements (the full xmlresume dtd/xsd). Likewise, we could convert a subset of xmlresume to hrxml."
Note that it is also possible to do a conversion directly, without requiring an intermediate format. I've made a first pass on that here:
Hi,
I´m going to develop a gui to help the building of the resumé, but i fear that the project its not solid enought for me to trust in his future, and i dont want to use a schema that will be bloated in a few months/years. Can the authors or someone give me some advice of what to do ????
Jayme
You certainly can't count on the XML Resume schema not changing for the next few years. There is already a beta release for the 2.0 version (although nothing has been done with it for quite some time), and I've heard that there are some changes waiting in the repository. Also, Matt LeClair is waiting to incorporate some of his own changes:
https://sourceforge.net/mailarchive/forum.php?thread_id=10121224&forum_id=1138
Also, note that XML Resume is not the only resume format in town. There is also the HR-XML standard:
http://cvsieve.sourceforge.net/
That said, may I offer a suggestion: Why not design your program in a modular way to make it future-proof? In other words, you could store all the data for the user's resume in your own custom format. You could then translate your custom format to and from any resume schema as needed. That way, if a schema changes, you only have to change the file translator, not your GUI. It would also allow you to support more than one resume format, not just the XML Resume type.
For example, you could store your GUI's data in a custom XML format, then write XSLTs to translate it into HR-XML and XML Resume formats.
By the way, will you be making this program open-source? I'd be interested in helping out.
I'm not sure how necessary a gui will be in the age of schema-aware XML editors/IDEs. If you use something like XMLSpy (for PC) or its free software equivalent, you can see what element should come next as you type out the resume. You can also see all the attribute names and what possible values they may have. I think this will get easier with a proper schema as opposed to the current DTD. A schema is certainly a priority item.
I never tried ORC (online resume creator) before it was taken down, but I think this allowed the user to create their resume through a series of web forms. If that's true, I think it would be a good solution. After a series of forms, the user would be able to download their resume in xml format (and perhaps pdf/text/etc). If a java gui is prefered by some users, it ought to be driven off the xmlresume schema (if it wishes to be compatible with this project). I'm not adept enough at java to take this on, but I would assume that a java app could read an xml schema and prompt the user for the quantity of elements of a given type ("job") and then ask for all the values required to fill it in.
I perused the cvsieve subversion viewer and it looks like there is some XSLT code (like attribute-sets) that could be helpful for xmlresume. What I'd like to see if some way to mimic style sheets so more than one PDF output is possible. This is easy with HTML by using CSS, but with XSLT it's much more difficult. You have to use template modes and it's not easy for someone to just contribute a new PDF style as a new file ("joe's style.xsl"). I don't know what the solution is there except to keep expanding parameters.xsl and restructuring fo.xsl. But that gets cumbersome.
I'll have to look at cvsieve more and compare it to the hr-xsl project. It seems like they share code. Right now there are 3 seperate sourceforge projects all primarily aimed at converting XML resumes into text and PDF. I'll have to give it some thought, but somehow these ought to be merged or made compatible with XSLT translations.
Although we could try to convert xmlresume's element names to match hrxml, it might be best to convert hrxml into an intermediate format which allows us to add more elements (the full xmlresume dtd/xsd). Likewise, we could convert a subset of xmlresume to hrxml. The xmlresume dtd/xsd would be what is ultimately used for PDF/text/html/rtf generation. That's the only way we can respond to all this feedback asking for more features while still maintaining a consistent element-naming scheme and compatiblity with HRXML.
Vocaro, I wanted to mention to you that your sample resume.xml and resume.pdf featured on the cvsieve's main page do not open. I had to look at copies from within your subversion repository. Thanks for keeping up with all the recent posts on this forum!
"I'm not sure how necessary a gui will be in the age of schema-aware XML editors/IDEs."
I think it will be very necessary. XML editors tend to be general-purpose and thus rather complex. They can easily overwhelm the user with all kinds of features that may be completely irrelevant to someone who just wants to create a resume. In addition, such editors don't have any domain-specific features. For instance, a custom app for handling XML resumes could add additional features like uploading the resume to a job site, performing a mail merge, or any other resume-specific automation technique that a generic XML editor couldn't do. In short, I'd much rather work with a resume editor that understands XML, rather than an XML editor that doesn't understand resumes.
"l have to look at cvsieve more and compare it to the hr-xsl project. It seems like they share code."
CV Sieve is nothing more than a fork of HR-XSL. You can think of it as HR-XSL 0.4; it includes bug fixes and a few new features compared to 0.3.
"Right now there are 3 seperate sourceforge projects all primarily aimed at converting XML resumes into text and PDF."
You mean XML Resume, CV Sieve, and HR-XSL? I would only count the first two. The HR-XSL project seems to have died, and with the CV Sieve project I'm trying to pick up where HR-XSL left off.
"What I'd like to see if some way to mimic style sheets so more than one PDF output is possible. This is easy with HTML by using CSS, but with XSLT it's much more difficult."
Yes, I've had the same concern. This is why I added a LaTeX converter to CV Sieve. That way, you can tweak the LaTeX output, making it look exactly how you want, then convert to PDF.
"Although we could try to convert xmlresume's element names to match hrxml, it might be best to convert hrxml into an intermediate format which allows us to add more elements (the full xmlresume dtd/xsd). Likewise, we could convert a subset of xmlresume to hrxml."
Note that it is also possible to do a conversion directly, without requiring an intermediate format. I've made a first pass on that here:
http://vocaro.com/trevor/software/resume/xmlresume-to-hrxml/
"Vocaro, I wanted to mention to you that your sample resume.xml and resume.pdf featured on the cvsieve's main page do not open."
Thanks; I'll take a look at it.
"Vocaro, I wanted to mention to you that your sample resume.xml and resume.pdf featured on the cvsieve's main page do not open."
Fixed it. Thanks for pointing that out!