There's been hardly any activity. I'd really like to see this project moving forward. I'm not an expert in XSLT or FOP, but if the project is officially open for adoption, I am willing to help out.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There isn't any development activity in the project and I have never received any feedback about the CSS file I developed so that XML Resumes could be edited in Vex.
Go ahead and try to contact the project admins.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The XML looks like it was designed by people who don't work with XML very much. The tags are mixed case, no dashes to separate words, and it seems overly verbose. Date representation needs some help as well. There doesn't seem to be anyway to indicate industry-specific sections of the document.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"The XML looks like it was designed by people who don't work with XML very much. The tags are mixed case,"
What's wrong with mixed-case tags? Besides, XMLResume has mixed case, too. (bookTitle, dayOfMonth, etc.)
"no dashes to separate words,"
You mean in the tags? XMLResume doesn't have those, either. In fact, it's very uncommon to see XML tags with dashes in them.
"and it seems overly verbose."
If by verbose you mean more detailed and comprehensive, this is the main reason why I prefer HR-XML over XMLResume. For instance, publication history is much more complete in HR-XML, providing fields for page number, ISBN, and so on. This allows more sophisticated XSL processing than XMLResume, which simply dumps all of a publication's metadata into a <description> field. For instance, with HR-XML, the user can toggle display of the ISBN on or off; this is currently not possible with XMLResume.
"Date representation needs some help as well."
Are you referring to HR-XML or HR-XSL? I agree that the latter is very much a work in progress, but the former has far better date handling than XMLResume.
"There doesn't seem to be anyway to indicate industry-specific sections of the document."
Yes, this is one feature of XMLResume that is not available in HR-XML. I've never had a need for it, however. Employers don't like to see gaps in work history, so I don't want to leave out a position just because it was in a different industry. What is more important, I think, is to limit work history to a certain timespan, but this is a feature that would be provided by the XSL, not the XML schema.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The primary tags used for 99% of the resume are all lower case tags, which makes it easier to read the content of the tags. It looks like publications were an add on and not necessarily part of the original design. Dashes are commonly used to separate words in standards such as XSL, or FO, SVG.
The primary benefit of the industry specific "targets" attributes is that I can keep a single document current more easily than I can keep multiple versions of my resume updated. For example, I'm a bioinformaticist. I write code, and I have specialized knowledge and skills in biology and medicine. When I apply for a job at a pharma, or biotech company they are interested in the scientific context of the projects that I've worked on. When I apply for a software engineering job, they have no interest in the scientific relevance of my work, but they DO want to know what API's and tools I've used. By providing industry-specific descriptions, I can generate a resume for either target audience.
As for my comment about verbose XML, I'm referring to the fact that it requires too many tags to represent a relatively simple concept. For example, in the case of a date (this occurs with both XMLResume and HR-XML), you have 6 tags to respresent something which should take only 1 line:
<date day="11" month="10" year="1975" />
As for publication history, I think there are more canonical forms that should be used to represent bibliographies. And those namespaces should be used within XMLResume rather than re-inventing the wheel.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"As for my comment about verbose XML, I'm referring to the fact that it requires too many tags to represent a relatively simple concept. For example, in the case of a date (this occurs with both XMLResume and HR-XML), you have 6 tags to respresent something which should take only 1 line:
<date day="11" month="10" year="1975" /> "
Take another look at the HR-XML schema definition. It includes several alternatives for specifying the date, including YearMonth and AnyDate, both of which require only one line. For instance:
<AnyDate>2005-06-18</AnyDate>
"As for publication history, I think there are more canonical forms that should be used to represent bibliographies. And those namespaces should be used within XMLResume rather than re-inventing the wheel."
Makes sense, but what are these canonical namespaces? Can you share some links?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There's BibTeXML (http://bibtexml.sourceforge.net/) an XML version of the popular BibTeX format, BibML(http://kmi.open.ac.uk/projects/ceryle/docs/NOTE-bibml.html), BibX (http://tex.aanhet.net/bibx), PubMedXML (http://www.nlm.nih.gov/bsd/licensee/data_elements_doc.html).. Any of these would be suitable; however, the my vote would always go for the least verbose implementation.
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 think the way we should do this in the future for xmlresume is to offer optional attributes in the date tag. If the attributes day, month, year are there, it will use those. If not, it will look for child elements. That's the only way I can think of to allow the creator of the resume to control the targeting (targets="...") since you can't specify an attribute of an attribute. There are several cases in the xmlresume schema where the number of elements required could be shortened. However, I'd still like to leave the option there for the user to apply the targeting filter if he/she wishes. Thus, having optional attributes and optional child elements should satisfy everyone.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I guess a better question would be - "Can I get what I need done with this project as is?" In my case the answer was "yes" and with a couple of minor tweaks to the Ant project file and the XSLTs I was able to get more out of it than I would have other wise, including getting the resume in Open Office.
My guess is, from the traffic on the site, this project has a lot of users, and most of them get what they need out of it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The HR-XSL project has XSLT for converting XML Resume to HR-XML. They're not comprehensive, but they can still save a lot of time. See: http://hr-xsl.sourceforge.net/doc/apa.html
Note that HR-XSL is based on the HR-XML 2.x spec, not the newer HR-XML 3.0 release. The conversion stylesheets therefore output HR-XML 2.x elements.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2010-07-29
I wonder what people on the list would think of forking the project? There have been a number of requests for changes that don't seem to have gotten anywhere. My first thought is to add groovy scripts for handling transformations and exports to Open Office and docx formats. Using groovy would have other benefits since FOP support (or support for any other library for that matter) can be easily included without having the user jump through hoops to add ant libraries.
Hopefully at some point it would be possible to create a web app or desktop app to let non-techie users manage their resume better. (Assuming there's enough interest in the community to contribute code for this).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you believe the project is dead and no longer being maintained, and you're willing to serve as the new maintainer, I suggest submitting an Abandoned Project Takeover request. This will avoid the disadvantages of a fork.
It has been three years since the last commit. I can't see any of the admin's contributing to this discussion. As such I think this project needs new admin. If you are interested in maintaining the project I would also recommend taking it over. Unfortunately I am already overloaded.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yeah, it's pretty much dead. Back when I was changing jobs frequently I had a lot more impetus to keep it going. I've had a stable position for 10 years now so I certainly have less motivation to continue.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This project is dead, and so is HR-XSL. That was killed off by wholesale changes to the schemas by HR-XML when they released 3.0, and the loss of motivation by the maintainer, as is always likely to happen. For example, there is no longer a Resume.xsd; it's been subsumed under Candidate as CandidatePerson and CandidateProfile.
I agree with the (old) comments about the complexity of HR-XML, but the main problem is that the consortium is not interested in "candidates" except for processing by consortium members. There is no way, for instance, to structure the description of the work you did with a particular position, apart from a single Description field. All of the "competency" and "experience" elements are designed for metrics and very closely defined categories, which are not useful for the vast majority of CVs produced by "candidates" like us.
The link above for cvsieve doesn't work either.
I think the HR-XML/hr-xsl combination is a good basis, but there needs to be a set of extension elements defined to give punters like us what we need to be able to produce CVs.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There's been hardly any activity. I'd really like to see this project moving forward. I'm not an expert in XSLT or FOP, but if the project is officially open for adoption, I am willing to help out.
There isn't any development activity in the project and I have never received any feedback about the CSS file I developed so that XML Resumes could be edited in Vex.
Go ahead and try to contact the project admins.
I've switched to HR-XML: http://hr-xsl.sourceforge.net/
The XML looks like it was designed by people who don't work with XML very much. The tags are mixed case, no dashes to separate words, and it seems overly verbose. Date representation needs some help as well. There doesn't seem to be anyway to indicate industry-specific sections of the document.
"The XML looks like it was designed by people who don't work with XML very much. The tags are mixed case,"
What's wrong with mixed-case tags? Besides, XMLResume has mixed case, too. (bookTitle, dayOfMonth, etc.)
"no dashes to separate words,"
You mean in the tags? XMLResume doesn't have those, either. In fact, it's very uncommon to see XML tags with dashes in them.
"and it seems overly verbose."
If by verbose you mean more detailed and comprehensive, this is the main reason why I prefer HR-XML over XMLResume. For instance, publication history is much more complete in HR-XML, providing fields for page number, ISBN, and so on. This allows more sophisticated XSL processing than XMLResume, which simply dumps all of a publication's metadata into a <description> field. For instance, with HR-XML, the user can toggle display of the ISBN on or off; this is currently not possible with XMLResume.
"Date representation needs some help as well."
Are you referring to HR-XML or HR-XSL? I agree that the latter is very much a work in progress, but the former has far better date handling than XMLResume.
"There doesn't seem to be anyway to indicate industry-specific sections of the document."
Yes, this is one feature of XMLResume that is not available in HR-XML. I've never had a need for it, however. Employers don't like to see gaps in work history, so I don't want to leave out a position just because it was in a different industry. What is more important, I think, is to limit work history to a certain timespan, but this is a feature that would be provided by the XSL, not the XML schema.
The primary tags used for 99% of the resume are all lower case tags, which makes it easier to read the content of the tags. It looks like publications were an add on and not necessarily part of the original design. Dashes are commonly used to separate words in standards such as XSL, or FO, SVG.
The primary benefit of the industry specific "targets" attributes is that I can keep a single document current more easily than I can keep multiple versions of my resume updated. For example, I'm a bioinformaticist. I write code, and I have specialized knowledge and skills in biology and medicine. When I apply for a job at a pharma, or biotech company they are interested in the scientific context of the projects that I've worked on. When I apply for a software engineering job, they have no interest in the scientific relevance of my work, but they DO want to know what API's and tools I've used. By providing industry-specific descriptions, I can generate a resume for either target audience.
As for my comment about verbose XML, I'm referring to the fact that it requires too many tags to represent a relatively simple concept. For example, in the case of a date (this occurs with both XMLResume and HR-XML), you have 6 tags to respresent something which should take only 1 line:
<date day="11" month="10" year="1975" />
As for publication history, I think there are more canonical forms that should be used to represent bibliographies. And those namespaces should be used within XMLResume rather than re-inventing the wheel.
"As for my comment about verbose XML, I'm referring to the fact that it requires too many tags to represent a relatively simple concept. For example, in the case of a date (this occurs with both XMLResume and HR-XML), you have 6 tags to respresent something which should take only 1 line:
<date day="11" month="10" year="1975" /> "
Take another look at the HR-XML schema definition. It includes several alternatives for specifying the date, including YearMonth and AnyDate, both of which require only one line. For instance:
<AnyDate>2005-06-18</AnyDate>
"As for publication history, I think there are more canonical forms that should be used to represent bibliographies. And those namespaces should be used within XMLResume rather than re-inventing the wheel."
Makes sense, but what are these canonical namespaces? Can you share some links?
There's BibTeXML (http://bibtexml.sourceforge.net/) an XML version of the popular BibTeX format, BibML(http://kmi.open.ac.uk/projects/ceryle/docs/NOTE-bibml.html), BibX (http://tex.aanhet.net/bibx), PubMedXML (http://www.nlm.nih.gov/bsd/licensee/data_elements_doc.html).. Any of these would be suitable; however, the my vote would always go for the least verbose implementation.
I think the way we should do this in the future for xmlresume is to offer optional attributes in the date tag. If the attributes day, month, year are there, it will use those. If not, it will look for child elements. That's the only way I can think of to allow the creator of the resume to control the targeting (targets="...") since you can't specify an attribute of an attribute. There are several cases in the xmlresume schema where the number of elements required could be shortened. However, I'd still like to leave the option there for the user to apply the targeting filter if he/she wishes. Thus, having optional attributes and optional child elements should satisfy everyone.
http://hr-xsl.sourceforge.net/ looks very, very complicated.
It's becoming a hard decision. I like xmlresume but I don't want to get used to a dead project and have to do the work all over again.
On the other hand hr-xsl looks impossibily complicated for my purposes. I can't even find a processor to download and try!
whoops, I got confused with the consortium
"http://hr-xsl.sourceforge.net/ looks very, very complicated."
What exactly is complicated about it? I don't think it's any more complicated that XMLResume.
"On the other hand hr-xsl looks impossibily complicated for my purposes. I can't even find a processor to download and try!"
Apache FOP is included with the HR-XSL distribution, so you don't need to download anything.
You should also check out CV Sieve:
http://cvsieve.sourceforge.net/
It's a direct fork of HR-XSL, but it includes a number of bug fixes and improvements.
I guess a better question would be - "Can I get what I need done with this project as is?" In my case the answer was "yes" and with a couple of minor tweaks to the Ant project file and the XSLTs I was able to get more out of it than I would have other wise, including getting the resume in Open Office.
My guess is, from the traffic on the site, this project has a lot of users, and most of them get what they need out of it.
hi
is a new release planned at least ?
if yes please check this issue :
http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=xml-resume-library&archive=no&pend-exc=pending-fixed&pend-exc=fixed&pend-exc=done&sev-inc=critical&sev-inc=grave&sev-inc=serious&repeatmerged=no
if no, are there xslt way to convert to xml-hr ?
regards
rzr,
The HR-XSL project has XSLT for converting XML Resume to HR-XML. They're not comprehensive, but they can still save a lot of time. See: http://hr-xsl.sourceforge.net/doc/apa.html
Note that HR-XSL is based on the HR-XML 2.x spec, not the newer HR-XML 3.0 release. The conversion stylesheets therefore output HR-XML 2.x elements.
ok thx
what about :
* Outstanding bugs - Serious (policy violations or makes package unfit for release); Unclassified (1 bug)
http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=xml-resume-library&archive=no&pend-exc=pending-fixed&pend-exc=fixed&pend-exc=done&sev-inc=critical&sev-inc=grave&sev-inc=serious&repeatmerged=no
I wonder what people on the list would think of forking the project? There have been a number of requests for changes that don't seem to have gotten anywhere. My first thought is to add groovy scripts for handling transformations and exports to Open Office and docx formats. Using groovy would have other benefits since FOP support (or support for any other library for that matter) can be easily included without having the user jump through hoops to add ant libraries.
Hopefully at some point it would be possible to create a web app or desktop app to let non-techie users manage their resume better. (Assuming there's enough interest in the community to contribute code for this).
If you believe the project is dead and no longer being maintained, and you're willing to serve as the new maintainer, I suggest submitting an Abandoned Project Takeover request. This will avoid the disadvantages of a fork.
https://sourceforge.net/apps/trac/sourceforge/wiki/Abandoned%20Project%20Takeovers
It has been three years since the last commit. I can't see any of the admin's contributing to this discussion. As such I think this project needs new admin. If you are interested in maintaining the project I would also recommend taking it over. Unfortunately I am already overloaded.
Yeah, it's pretty much dead. Back when I was changing jobs frequently I had a lot more impetus to keep it going. I've had a stable position for 10 years now so I certainly have less motivation to continue.
If you grant me scm commit i'd like to merge the debian patches and built snapshot packages :
http://rzr.online.fr/q/snapshot
regards
This project is dead, and so is HR-XSL. That was killed off by wholesale changes to the schemas by HR-XML when they released 3.0, and the loss of motivation by the maintainer, as is always likely to happen. For example, there is no longer a Resume.xsd; it's been subsumed under Candidate as CandidatePerson and CandidateProfile.
I agree with the (old) comments about the complexity of HR-XML, but the main problem is that the consortium is not interested in "candidates" except for processing by consortium members. There is no way, for instance, to structure the description of the work you did with a particular position, apart from a single Description field. All of the "competency" and "experience" elements are designed for metrics and very closely defined categories, which are not useful for the vast majority of CVs produced by "candidates" like us.
The link above for cvsieve doesn't work either.
I think the HR-XML/hr-xsl combination is a good basis, but there needs to be a set of extension elements defined to give punters like us what we need to be able to produce CVs.
It seems like someone could rewrite this entire thing in JavaScript or something similar? In fact it could just be a web page?