Re: sdmx dsds
Bob Jolliffe
On 28 May 2010 16:17, Bob Jolliffe <bobjo...@gmail.com> wrote:
> Hi Luke
>
> I've just updated a few things on launchpad.
>
> Included is a sample dataset (sample2) for the HR form. As I said
> earlier, this might be the easiest way for you to produce the actual
> dataset.
>
> I've added a VALUE_TYPE dimension as per the SDMX-HD standard which
> can be attached at either group or observation level (Ryan I've
> updated the two samples in sample1 to show both). In general it is
> better to attach at group level but either way is acceptable.
>
> Luke, the purpose of VALUE_TYPE is to distinguish between real data
> values (1) or target values (0). Its useful in this instance because
> I can prepare a dataset with target values as shown in the sample.
> Actual data that you provide should have value_type of 1.
>
> It is still my sense that the easiest most robust scenario is for you
> to work off this target dataset+schema and generate your reports
> accordingly. The target dataset lists all the required observations
> and the reporting period (which are not provided in the DSD). The
> schema provides all the valid options for attributes.
>
> BTW I still have to lookup how to represent a 6 monthly duration in
> ISO8601. Ryan, relooking at ISO8601, I think I currently have this
> wrong http://en.wikipedia.org/wiki/ISO_8601#Time_intervals :-(
>
> P1Y indicates a period of 1 year. P6M represents a period of 6
> months. P1M is one month etc.
>
> Well actually its not me that has it wrong. It seems its the SDMX
> specification. The spec says that the TIMEPERIOD type should be of
> type xsd:duration.which is exactly that - a duration. Not a named
> month, or year or week. Which is a problem. Not sure the solution
> right now.
OK on relooking well the spec doesn't quite say that but anyway its
confusing :-( Can you take a look and tell me what you think? I
don't want to waste too much time over this, but also want to get it
right. We want to all finalize our code fairly soon. I've got some
ideas but maybe some fresh eyes will help.
I have tried:
<structure:TimeDimension crossSectionalAttachGroup="true"
conceptRef="TIME_PERIOD" conceptSchemeRef="CS_COMMON"
conceptVersion="1.0" conceptSchemeAgency="SDMX-HD">
<structure:TextFormat textType="ObservationalTimePeriod"/>
</structure:TimeDimension>
which seems right to me, but the schema generated by the metadata
tools doesn't seem to agree ...
Regards
Bob
> Cheers
> Bob
>
> On 19 May 2010 20:27, Luke Duncan <ldu...@intrahealth.org> wrote:
>> Hi Bob,
>>
>> Actually, after thinking about it a bit, maybe it would be easier in multiple files. I've been going back and forth on reading those files directly or just loading them into my database. Loading them is easier in one file, but separate files are probably easier for accessing directly. I think the problem I had with the SDMX-HD was that it seemed it was possible to have multiple files for one code list. For example you may use CL_GENDER but you want to add a few so you add your customizations in a separate file. Is that correct?
>>
>> For now, I'll have it work either way. If you want to break them out, I'll read them separately, but it should work to read them from a single file as well. I hope to be able to have something working tomorrow on this for the reading part. Then I'll work on the linking and reporting aspect.
>>
>> Thanks!
>> Luke
>>
>>> -----Original Message-----
>>> From: Bob Jolliffe [mailto:bobjo...@gmail.com]
>>> Sent: Wednesday, May 19, 2010 1:37 PM
>>> To: Luke Duncan
>>> Cc: Ryan
>>> Subject: Re: sdmx dsds
>>>
>>> Hi Luke
>>>
>>> On 19 May 2010 17:28, Luke Duncan <ldu...@intrahealth.org> wrote:
>>> > Hi Bob,
>>> >
>>> > Thanks for doing this. I'm still trying to work out in my head the
>>> best
>>> > way to load and link this data. I have a couple quick questions,
>>> > though. Does this DSD have all the required code lists or only the
>>> ones
>>> > that are SL specific?
>>>
>>> This has all the required code lists for the SL current scenario. We
>>> cannot use the SDMX-HD COMMON codelists at this point because our
>>> dataelements and dimensions are defined from the paper forms. So they
>>> are all custom. Except I think for the period type which uses SDMX-HD
>>> COMMON. And we are using the SDMX-HD COMMON concept schemes.
>>>
>>> >If not, is there a version of the SDMX-HD code
>>> > lists in this format instead of the zip with a file for each code
>>> list?
>>>
>>> You prefer them like this? I was just about to break them out and
>>> make them external references. I'll leave them where they are for
>>> now. Note the common concept scheme is in an external file.
>>>
>>> I don't think there is an existing version of all the SDMX-HD COMMON
>>> codelists in one file, but I guess they would be easy enough to stick
>>> together. It is a better practice to have them as external references
>>> because then things other than the DSD eg. a metadata report can refer
>>> to the same lists. Reuse ... But its also handy to have them in one
>>> stream for ease of processing. I hate zip.
>>>
>>> I didn't get around to doing any sample data - been busy trying to
>>> figure out how best to filter. I'll try and squeeze in some time this
>>> evening.
>>>
>>> Regards
>>> Bob
>>>
>>> > I didn't see anything on the website. Actually I didn't even see a
>>> way
>>> > to download the zip file from the website, but I have a copy of it.
>>> >
>>> > Thanks!
>>> > Luke
>>> >
>>> >> -----Original Message-----
>>> >> From: Bob Jolliffe [mailto:bobjo...@gmail.com]
>>> >> Sent: Tuesday, May 18, 2010 8:13 PM
>>> >> To: Luke Duncan; Ryan
>>> >> Subject: sdmx dsds
>>> >>
>>> >> Hi Luke and Ryan
>>> >>
>>> >> I've just updated the latest metadata from dhis onto launchpad at
>>> >> lp:~bobjolliffe/+junk/sdmx-hd
>>> >>
>>> >> A few comments:
>>> >> 1. This is the complete dxf dump so it (and the resulting dsd is
>>> >> fairly large). You will generally only be interested in small parts
>>> >> of it
>>> >> 2. You can generate an xsd schema for a particular keyfamily with
>>> >> the create_xsd script
>>> >> eg. ./create_xsd.sh KF_360523 dsd/DSD_2010_05_07.xml
>>> >> schema/staffing.xsd
>>> >> 3. I will look tomorrow at filtering so that there is only the
>>> >> relevant orgunits and codelists for particular scenarios
>>> >> 4. You will notice that, as threatened, I have introduced a
>>> FACILITY
>>> >> dimension. I have indicated that this can be attached at OBS level
>>> or
>>> >> at GROUP level. This might offer some flexibility in grouping of
>>> >> obs_values by facility which would mostly be of interest to iHRIS -
>>> >> who would report data for many facilities. In OpenMRS case it would
>>> >> generally be one (or a few). Thinking about it, even then you will
>>> >> probably want to attach the FACILITY attribute to the group. Maybe
>>> >> I'll remove its OBS level attachment.
>>> >> 5. I haven't made sample data and its late now. Will do so in the
>>> >> morning.
>>> >> 6. There's quite a few files which shouldn't be under version
>>> control
>>> >> because they are generated or copied from elsewhere. I've committed
>>> >> them all for convenience. if you can both use xsltproc on linux
>>> I'll
>>> >> remove the generated files. Luke I am sure you can. Ryan I am not
>>> >> sure if your dev env is windoze or linux and how you would run
>>> scripts
>>> >> on windoze. Probably cygwin or something similar. Or maybe convert
>>> >> to batch file and run with whichever xlt processor might be
>>> available.
>>> >>
>>> >> Good night
>>> >> Bob
>>> >>
>>> >> PS. I have an issue with breaking up the DSD into smaller parts and
>>> >> referencing with isExternal="true" href="..." which is due to the
>>> fact
>>> >> that I am still taking pains to avoid xslt 2.0. By setting the xslt
>>> >> version to the (stillborn) v1.1 I can use document() to output
>>> >> fragments but they will not be indented. I don't have a problem
>>> with
>>> >> this, but if you are viewing with a simple text editor it will be
>>> >> ugly. Ultimately its not about viewing but parsing so I will
>>> probably
>>> >> do this anyway. You can always prettify with 'xmllint --format
>>> ...'.
>>> >> But for the moment its all (almost) in one big stream.
>>> >>
>>> >> No virus found in this incoming message.
>>> >> Checked by AVG - www.avg.com
>>> >> Version: 9.0.819 / Virus Database: 271.1.1/2881 - Release Date:
>>> >> 05/18/10 02:26:00
>>> >
>>
>
Ryan
I see both the Header element and the DataSet element both have reportingStart and reportingEnd elements. Perhaps this is what we should be using instead. I'm struggling at the moment with where FREQ and the TIME_PERIOD should be defined by the user of my module or how it could be set.
According to the documentation in the scheme only GenericData, CompactData, and UtilityData message are required to have a TimeDimension so maybe we can just leave it out for the CrossSectional message? I don't really see a use for FREQ or TIME_PERIOD for our use case if we already have the reporting start and end dates.
If frequency is required then I see there can also be a attribute for frequency instead of a dimension. It would be much easier for me if we do it this way.
Let me know what you think.
Thanks,
Ryan
Ryan Crichton
Software Developer
ry...@jembi.org
http://www.jembi.org
Bob Jolliffe
On 31 May 2010 12:59, Ryan <rg.cr...@gmail.com> wrote:
> Hi Bob,
>
> I see both the Header element and the DataSet element both have
> reportingStart and reportingEnd elements. Perhaps this is what we should be
> using instead. I'm struggling at the moment with where FREQ and the
> TIME_PERIOD should be defined by the user of my module or how it could be
> set.
>
> According to the documentation in the scheme only GenericData, CompactData,
> and UtilityData message are required to have a TimeDimension so maybe we can
> just leave it out for the CrossSectional message? I don't really see a use
> for FREQ or TIME_PERIOD for our use case if we already have the reporting
> start and end dates.
Agree that there seems to be some overlap with reporting start and
reporting end date, but I'm not sure if this is exactly the same
thing. For example you might report a whole year's worth of monthly
data with report start date = 01/01/2010 and end date 31/12/2010. But
the actual observations might be for monthly periods within the
reporting period. This would particularly be the case with time
series data but could also be the case with a messagegroup of
cross-sectional datasets.
According to the standard, what we should have on that timedimension
is a restriction of common:TimePeriodType (see the definition below
from SDMXCommons.xsd) where the TextType of the TimeDimension in the
DSD is ObservationalTimePeriod (see the definition below from
SDMXStructure.xsd). It just seems that the xslts provided by metadata
technology is failing to process that. That looks like a bug to me
and I will fix it for the xslts I am using to generate the keyfamily
specific schema and update on launchpad shortly.
This would mean that the following formats are acceptable values of
the TIME_PERIOD attribute:
2010-06 - thats the one you would use which corresponds to monthly data
2010 - for annual data
2010-B1 - for the first 6 months of 2010 (Bi-annual data - that was
the one I didn't know :-) )
2010-W3 - week 3 of 2010 (I guess we assume ISO8601 week numbering.
Less weekly data the better - its generally horribly messy!)
2010-Q3 - 3rd quarter of 2010
[For financial year periods Gary came up with the excellent idea of
the calendar type attribute which could be used to offset these, but
fortunately that doesn't concern us right now]
Regarding how to set FREQ and TIME_PERIOD in your UI I guess there are
different possibilities. The problem is of course that the DSD isn't
going to tell you to generate a monthly report. You know you must, I
know you must, SL-MOHS knows you must. Even DHIS knows that it is
expecting it. But the DSD is going to tell that to OpenMRS by
providing a keyfamily. I kind of think this information should be
provided as a data provision agreement but lets not introduce too much
complexity yet.
If the openmrs reporting framework doesn't have a notion of
periodicity (it just has start and end date) then I guess your user
can just set the start and end date in your UI, and your module would
have to calculate the FREQ and TIME_PERIOD attributes off that. There
is a danger there that the user generates reports for strange periods
(I see for example that the sample screenshots generate for 1/10/2009
to 15/10/2009). This is obviously just a sample, but it would
definitely cause a problem on the receiving end where it would have to
be read into a dhis dataelement which captures monthly data. It is
definitely better that you produce these attributes up front as
otherwise the receiving system is going to have to validate the dates
and reject the report if it is out of bounds. Better to catch this
horse before it leaves the stable.
I think if I were you I would restrict this choice in your user
interface ie. instead of start-end date have an entry input box which
only accepts YYYY-MM (you could also have a calendar control which
only selects the month). Then you can easily work out the start and
ends dates off that to perform the actual report query.
I guess that still leaves it open how to report data other than
monthly data. Looking at the SDMX-HD CL_FREQ codelist, if you wanted
to be completely generic and complete you would need to support the 9
different reporting frequencies defined there (annually, half-yearly,
quarterly, monthly etc ...). For that you'd probably need a drop down
list which placed a constraint on the time period input depending on
which frequency is selected. Supporting all the frequencies is maybe
a bit complicated to do in a short time - I think all the immediate
required reports are for monthly data so maybe you can hardcode that
for version 1 then add support for the rest later.
Regards
Bob
======== common:TimePeriodType from SDMXCommons.xsd
================================================================
<xs:simpleType name="PeriodType">
<xs:annotation>
<xs:documentation>PeriodType provides a list of tokens for
specifying common periods: Quarterly: Q1, Q2, Q3, Q4; Weekly: W1 -
W52; Triannual: T1, T2, T3; Biannual: B1, B2. These values appear
after a four-digit year indicator, followed by a dash (ie,
2005-Q1).</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string">
<xs:pattern
value="(\d\d\d\d\-Q1|\d\d\d\d\-Q2|\d\d\d\d\-Q3|\d\d\d\d\-Q4|\d\d\d\d\-T1|\d\d\d\d\-T2|\d\d\d\d\-T3|\d\d\d\d\-B1|\d\d\d\d\-B2|\d\d\d\d\-W1|\d\d\d\d\-W2|\d\d\d\d\-W3|\d\d\d\d\-W4|\d\d\d\d\-W5|\d\d\d\d\-W6|\d\d\d\d\-W7|\d\d\d\d\-W8|\d\d\d\d\-W9|\d\d\d\d\-W10|\d\d\d\d\-W11|\d\d\d\d\-W12|\d\d\d\d\-W13|\d\d\d\d\-W14|\d\d\d\d\-W15|\d\d\d\d\-W16|\d\d\d\d\-W17|\d\d\d\d\-W18|\d\d\d\d\-W19|\d\d\d\d\-W20|\d\d\d\d\-W21|\d\d\d\d\-W22|\d\d\d\d\-W23|\d\d\d\d\-W24|\d\d\d\d\-W25|\d\d\d\d\-W26|\d\d\d\d\-W27|\d\d\d\d\-W28|\d\d\d\d\-W29|\d\d\d\d\-W30|\d\d\d\d\-W31|\d\d\d\d\-W32|\d\d\d\d\-W33|\d\d\d\d\-W34|\d\d\d\d\-W35|\d\d\d\d\-W36|\d\d\d\d\-W37|\d\d\d\d\-W38|\d\d\d\d\-W39|\d\d\d\d\-W40|\d\d\d\d\-W41|\d\d\d\d\-W42|\d\d\d\d\-W43|\d\d\d\d\-W44|\d\d\d\d\-W45|\d\d\d\d\-W46|\d\d\d\d\-W47|\d\d\d\d\-W48|\d\d\d\d\-W49|\d\d\d\d\-W50|\d\d\d\d\-W51|\d\d\d\d\-W52)"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="TimePeriodType">
<xs:annotation>
<xs:documentation>TIME_PERIOD is not completely expressable in XML
Schema's date type: instead we use the union of dateTime, date,
gYearMonth, and gYear. The default name for the concept is
TIME_PERIOD. Bi-annual, tri-annual, quarterly, and weekly periods have
special formats (see PeriodType, above), but other periods would be
described in terms of their beginning date or time (eg, a period of a
decade is identified with a four-digit year corresponding to the
decades' first year).</xs:documentation>
</xs:annotation>
<xs:union memberTypes="xs:dateTime xs:date xs:gYearMonth xs:gYear
PeriodType"/>
</xs:simpleType>
======== ObservationalTimePeriod from SDMXStructure.xsd
================================================================
<xs:enumeration value="ObservationalTimePeriod">
<xs:annotation>
<xs:documentation>This is a time datatype, and is the
conventional representation of time in SDMX formats. It is a union of
W3C XML Schema time datatypes and a set of codes for indicating
quarterly, tri-annual, bi-annual, and weekly time periods. See
common:TimePeriodType for specifics.</xs:documentation>
</xs:annotation>
</xs:enumeration>
==================================================================================================================
r.friedman
surveillance data. In the US, we use the CDC concept of Epi Week, which
corresponds to ISO-8601. However, I have seen countries that use the first
week entirely in the calendar year as their week 1.
Hi Ryan
Regards
Bob
============================================================================
======================================
--
You received this message because you are subscribed to the Google Groups
"SDMX-HD (Health Domain)" group.
To post to this group, send email to sdm...@googlegroups.com.
To unsubscribe from this group, send email to
sdmx_hd+u...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sdmx_hd?hl=en.
Bob Jolliffe
> Re week number -- Most health departments use the concept of an Epi Week for
> surveillance data. In the US, we use the CDC concept of Epi Week, which
> corresponds to ISO-8601. However, I have seen countries that use the first
> week entirely in the calendar year as their week 1.
Hi Roger
That's interesting information. How or where is an Epi Week defined?
I know the thinking of Gary was that the calendar type would be used
to differentiate between a January to December year and a (USG) fiscal
year. I guess one could also use the calendar type (with appropriate
metadata attached) to say something about the week numbering system
too.
Regards
Bob
r.friedman
Here it is called "MMWR week" for CDC's publication "Morbidity & Mortality
Weekly Report". Of the equivalent definitions in ISO-8601, this one is that
week 1 is the first week (Sun-Sat) that contains at least 4 days in the new
year.
As for other countries, that comes from answering questions fielded by the
Epi Info help desk during my years on that project.
Hi Roger
Regards
Bob
> 9|4|\d\d
> \d\d\-W25|\d\d\d\d\-W26|\d\d\d\d\-W27|\d\d\d\d\-W28|\d\d\d\d\-W29|\d\d
> \d\d\-
> W30|\d\d\d\d\-W31|\d\d\d\d\-W32|\d\d\d\d\-W33|\d\d\d\d\-W34|\d\d\d\d\-
> W30|W35|\d
> ====== ======================================
Bob Jolliffe
> http://www.cdc.gov/ncphi/disss/nndss/phs/mmwrweek/MMWR_Week_Fact_Sheet.doc
>
> Here it is called "MMWR week" for CDC's publication "Morbidity & Mortality
> Weekly Report". Of the equivalent definitions in ISO-8601, this one is that
> week 1 is the first week (Sun-Sat) that contains at least 4 days in the new
> year.
Ok. I guess this measure would be similar to the ISO week number.
Except for starting on a Monday, I think MMR week n will always
overlap six days with ISO week n.
It doesn't help that most folk simply believe that the week number is
what Excel tells them - and excel can be horribly confused on this
point. Excel 2003
(http://office.microsoft.com/en-us/excel/HP052093371033.aspx) refers
to a "European standard" which is different to what Excel does. I
guess they meant ISO.
Excel 2010 - which should theoretically now support the ISO/IEC
29500:2008 format known as OOXML - is still a bit confused over ISO
standard week numbering. Ron de Bryn of the Excel team has a useful
blog here (http://blogs.msdn.com/b/excel/archive/2009/06/30/week-numbers-in-excel.aspx)
where he provides some very useful workarounds which could be adapted
to work with different weeknumber types.
Meanwhile the OASIS Office TC (which manages ODF) has just approved
the publishing of ODF1.2 for public review so I expect OASIS will
publish that in the next few days. Part 2 of the ODF spec defines
something called openformula for spreadsheets. One of the most
difficult tasks has been to maintain compatibility with excel and
still make sense at the end of the day. The WEEKNUM function has been
a case in point. Fortunately we have had Microsoft join the TC and
they have contributed information on what Excel actually does rather
than what the documentation says it does. So OpenFormula defines
WEEKNUM (which does what excel does) and also an additional function
ISOWEEKNUM. This function determines the ISO week number and takes
an additional mode parameter which determines whether to use a week
starting on Sunday (mode 1) or Monday (mode 2). So I guess it would
be quite suitable for MMR weeks :-)
>
> As for other countries, that comes from answering questions fielded by the
> Epi Info help desk during my years on that project.
Sadly I don't see this changing soon. Didn't realize you worked on
EpiInfo. Great program - well the dos version was.
Cheers
Ryan
Here is a new generated Cross Sectional DataSet. Let me know if it how you expect.
Regards,
Ryan
Bob Jolliffe
I am picking up a few validation errors (see below). It looks a lot
but its not really. Basically:
1. Time formats for your reporting start and end dates in the header
and the dataset. The xml schema datetime type doesn't like
'2010-06-01T00:00:00+0200'. It is happy with
'2010-06-01T00:00:00.0200' or even '2010-06-01'
2. Your dataset id 'OpenMRS export' shouldn't have a space.
'OpenMRS_export' is valid. I'm still wondering how best to make use
of this attribute. What do you think of using the id from the paper
form - eg PHU-F3. At least this could be useful information.
Otherwise all looks fine.
Cheers
Bob
SystemID: /home/bobj/src/xslt/sdmx/dhis/data/sample_ryan/Data_CROSS.xml
Engine name: Xerces
Severity: error
Description: cvc-datatype-valid.1.2.3: '2010-06-01T00:00:00+0200' is
not a valid value of union type 'HeaderTimeType'.
Start location: 18:66
URL: http://www.w3.org/TR/xmlschema-2/#cvc-datatype-valid
SystemID: /home/bobj/src/xslt/sdmx/dhis/data/sample_ryan/Data_CROSS.xml
Engine name: Xerces
Severity: error
Description: cvc-type.3.1.3: The value '2010-06-01T00:00:00+0200' of
element 'ReportingBegin' is not valid.
Start location: 18:25
End location: 18:49
URL: http://www.w3.org/TR/xmlschema-1/#cvc-type
SystemID: /home/bobj/src/xslt/sdmx/dhis/data/sample_ryan/Data_CROSS.xml
Engine name: Xerces
Severity: error
Description: cvc-datatype-valid.1.2.3: '2010-06-30T00:00:00+0200' is
not a valid value of union type 'HeaderTimeType'.
Start location: 19:62
URL: http://www.w3.org/TR/xmlschema-2/#cvc-datatype-valid
SystemID: /home/bobj/src/xslt/sdmx/dhis/data/sample_ryan/Data_CROSS.xml
Engine name: Xerces
Severity: error
Description: cvc-type.3.1.3: The value '2010-06-30T00:00:00+0200' of
element 'ReportingEnd' is not valid.
Start location: 19:23
End location: 19:47
URL: http://www.w3.org/TR/xmlschema-1/#cvc-type
SystemID: /home/bobj/src/xslt/sdmx/dhis/data/sample_ryan/Data_CROSS.xml
Engine name: Xerces
Severity: error
Description: cvc-datatype-valid.1.2.3: '2010-06-01T00:00:00+0200' is
not a valid value of union type 'TimePeriodType'.
Start location: 22:100
URL: http://www.w3.org/TR/xmlschema-2/#cvc-datatype-valid
SystemID: /home/bobj/src/xslt/sdmx/dhis/data/sample_ryan/Data_CROSS.xml
Engine name: Xerces
Severity: error
Description: cvc-attribute.3: The value '2010-06-01T00:00:00+0200' of
attribute 'reportingBeginDate' on element 'ns:DataSet' is not valid
with respect to its type, 'TimePeriodType'.
Start location: 21:36
End location: 21:62
URL: http://www.w3.org/TR/xmlschema-1/#cvc-attribute
SystemID: /home/bobj/src/xslt/sdmx/dhis/data/sample_ryan/Data_CROSS.xml
Engine name: Xerces
Severity: error
Description: cvc-datatype-valid.1.2.3: '2010-06-30T00:00:00+0200' is
not a valid value of union type 'TimePeriodType'.
Start location: 22:100
URL: http://www.w3.org/TR/xmlschema-2/#cvc-datatype-valid
SystemID: /home/bobj/src/xslt/sdmx/dhis/data/sample_ryan/Data_CROSS.xml
Engine name: Xerces
Severity: error
Description: cvc-attribute.3: The value '2010-06-30T00:00:00+0200' of
attribute 'reportingEndDate' on element 'ns:DataSet' is not valid with
respect to its type, 'TimePeriodType'.
Start location: 22:26
End location: 22:52
URL: http://www.w3.org/TR/xmlschema-1/#cvc-attribute
SystemID: /home/bobj/src/xslt/sdmx/dhis/data/sample_ryan/Data_CROSS.xml
Engine name: Xerces
Severity: error
Description: cvc-pattern-valid: Value 'OpenMRS export' is not
facet-valid with respect to pattern '([A-Z]|[a-z]|\*|@|[0-9]|_|$|\-)*'
for type 'IDType'.
Start location: 22:100
URL: http://www.w3.org/TR/xmlschema-2/#cvc-pattern-valid