#12 Targeted resumes

[Paul A. Hoadley]

It was always an aim of the ResXML project to allow
"targeted" resumes, by which I mean the ability to
produce multiple different output documents, based on a
single XML source file, according to certain
conditions. That is, if I mark a certain section of my
source as, say, "for hamburger-flipping jobs", and
another section as "for brain surgery jobs", then I can
later generate any combination of none, both or either
of those sections based on some configuration at
run-time. So I can target my resume according to the
job for which I am currently applying.

Similarly, some sections of the source file might be
forever out of date, and I might want to mark certain
sections as "archived", and not for retrieval under any
condition. I don't know whether this necessarily needs
to be a separate concept to the targeting concept
described above, so we'll consider them together for now.

The obvious solution would be to have a "target"
attribute on certain elements. (Or any elements?)
This attribute would be checked by the stylesheets and
compared to, say, a parameter specified at run-time.
(Referring to the previous paragraph again, does it
make sense to have both a "target" attribute and, say,
a "visibility" attribute?) Would we require a change
in the schema? For example, are there any cases where
we currently allow for some element to be optional
where we might want to allow for zeroOrMore?

[Phil Roberts]

Logged In: YES
user_id=1150612

I don't think there's any reason to have both 'visibility'
and 'target' attributes.

[Paul A. Hoadley]

Logged In: YES
user_id=351618
Originator: YES

I committed "common/targets.xsl" in January 2005. That looks like a simple filter based on finding a set of one or more keywords in a list of keywords supplied as the value of the 'targets' attribute. There's also a couple of elements in "examples/john_doe.xml" that have that attribute. I've just tried feeding it john_doe.xml, but it's buggy. I'm debugging it.

[Paul A. Hoadley]

Logged In: YES
user_id=351618
Originator: YES

I fixed a small bug in "common/targets.xsl" (I had moved the 'cross-compare' template out of this file). It now works. The behaviour is as follows:

1. The template is supplied with a "targets" parameter, which is a comma-separated list of keywords. (In fact, the comma is arbitrary and can be replaced by a character supplied as the 'list-separator' parameter.)
2. The template checks every element in the input for the 'targets' parameter. If an element has no 'targets' parameter, it is copied to output, and checking continues.
3. If an element has a 'targets' parameter, the template checks whether one or more of the supplied keywords can be found in the value of the 'targets' parameter. For example, if the supplied list is "alpha,beta" an element has a 'targets' attribute containing "beta,gamma,delta", this would be a match since "beta" is present in both lists. If there is no match, the element _and its children_ are not copied to output, and checking resumes on the element's following-sibling. If there is a match, the element is copied to output, and checking resumes on the element's first child.

This is a pretty simple implementation, but I can't think of anything we would need that it cannot achieve.