I would be interested to know if this is a XMLSpy specific thing or that
other validating editors and/or parsers are as strict. Is there anyone using
an editor/parser that is as strict?
Pierre Gorissen
IT Consultant
Fontys University of Professional Education
Educational Development Department
> ----------
> Van: Andy Powell[SMTP:[log in to unmask]]
> Verzonden: zondag 13 april 2003 10:08:05
> Aan: [log in to unmask]
> Onderwerp: Re: LOM Test Data
>
On Sat, 12 Apr 2003, Gorissen,Pierre P.J.B. wrote:
> It looks like the strict check by XMLSpy is causing more problems related
to the <language></language> element.
> I had a look at the banana example
(http://www.rdn.ac.uk/resourcefinder/?query=banana) and the first four
entries there fail to validate in XMLSpy:
>
> http://www.rdn.ac.uk/record/lom/oai:rdn:agrifor:2011603
> http://www.rdn.ac.uk/record/lom/oai:rdn:agrifor:2024084
> http://www.rdn.ac.uk/record/lom/oai:rdn:agrifor:2011641
> http://www.rdn.ac.uk/record/lom/oai:rdn:agrifor:2014720
>
> This is because <language>eng</language> is used in the records instead
> of <language>en</language> or <language>en-UK</language>
Hmmm... that is a slight pain. The current RFC for language tags is
RFC-3066
http://www.ietf.org/rfc/rfc3066.txt
which allows both 2 and 3 letter language codes. This is what Dublin Core
now suggests using and is what I recommend in the RDN/LTSN application
profile. Unfortunately XML doesn't seem to have caught up with this :-(
Looks like I'll have to go back to refering to RFC-1766 OR explicitly
state that only 2-letter language codes from RFC-3066 are allowed.
For now, I've also added an explicit fix for 'eng'->'en' in my DC->LOM
output filter for RDN records. So all the records abaove should be OK.
Andy.
|