Here's a quick run-down on your questions.
> 1) I got to know from one of the members in our team that
> HR-XML 3.0 final release is due October 16th 2008; however I
> could not get the final release on the site as yet. Could you
> please let us know as to when we can expect that?
We're aiming for the near-final, Candidate Release next week. It will go through a 60-day public review period, followed by reconciliation of any feedback - So the final, official version should be available the first of the year.
> 2) Where can I get information regarding extending the
> existing schema for customizing to suit our needs. I did find
> it for 2.5 but not for 3.0
The same principles apply, but it is easier in 3.0.
***** 1 **** UserAreas are more abundant. Also, note that the HRUserAreaType uses processContents="lax". This is a change from 2.*, which specified "strict"
processContents attribute. Possible values for this are "skip" (meaning that an XML processor will ignore what is in the UserArea); "lax" (asking the processor to validate the contents when possible); and "strict" (meaning validation will be attempted.
It is still good practice to validate UserArea content with your own schema and to specify such extensions under your own namespace -- So everything you did in 2.* should work with 3.0. However, using "lax" most processors will look for a schema against which to validate the content, but won't throw a validation error if it doesn't find one. The UserArea extensions will of course still need to be well-formed. You also ought to declare a namespace prefix for the extensions even if you don't specify the schema against which to valid the XML. For an example (recruiting), see:
http://www.hrinterop.org/schemas/OAGi-BPI-Platform/org_hr-xml/3_0/Instan...
Notice the declaration of the namespace prefix and its use:
<ProcessCandidate .... xmlns:ext="http://resumeparsingco.com" ....>
[snip]
<UserArea>
<ext:ProcessingComment>(*CO. NAME PROBABILITY = 4096; *POS. TITLE PROBABILITY = 658) (*Offset of farthest data found = 87)</ext:ProcessingComment>
</UserArea>
***** 2 **** In 3.0, you'll see that we did away with the "stringPatternExtension" for enumerated values. However, you'll find that most code lists are set up as "Open Lists" -- i.e., they allow for additional values other than those that are enumerated. Really this is not very different that 2.5. In 2.5, the code lists that used the stringPatternExtension essentially documented a set of "suggested values" and allowed implementers to specify others using "x:". 3.0 works the same way, but you don't need to include "x:" in front of your extended values.
> 3) What should we be using in case of Error conditions
> during the Screening Order fulfillment. The documentation
> mentions about ConfirmBOD but I am not too sure as to how to
> use it. Can I get some samples, examples using that.
This is a good question. I'll see if I can supply some examples. It would be *** very *** helpful to me if you supplied me with one or two scenarios as well. What would be common error causes and information you would need to report back? A sentence or two for each scenario and some sample data would be very useful.
> 4) For screening we have planned to use the
> ScreeningReport.xsd and one of the elements within the xsd is
> "AccessPointDetails" which contains the URL information for
> the screening result. While going through Visual Schema site
> (http://www.visualschema.com/vs/hr-xml/ScreeningReport/) for
> hr-xml, I came across something similar in (Screening Report
> -> Screening Package Result -> Screening Result -> Screening
> Report Access Details) and it contains elements like "Valid
> From" & "Valid To" also which are something which we would
> like to have in terms of availability of the result.
>
> So my question is do we have something similar in the xsd
> if yes then which xsd should I refer? It is quite possible
> that visual schema site doesn't have the actual
> representation of the draft version; however just wanted to
> confirm.
EffectiveDateAttributeGroup is specified on the AccessPointDetails, which gives you what I believe you want. See below and attached.
The validTo / validFrom is our generalized mechanism for "effective dating" -- representing when a set of facts are in force -- In this case, the period during which the information about the access point (and presumably the access itself) is valid.
http://www.hrinterop.org/schemas/OAGi-BPI-Platform/org_hr-xml/3_0/Docume...
