MRTG v0.9 XML Schema Issues
→ Information about submission as TDWG standard
→ MRTG Wiki Homepage
→ Current Schema Draft. This version is under internal review as part of the submission to TDWG.
→ Audubon Core Non normative document
→ MRTG Development History
→ MRTG Meeting Notes
→ MRTG Best Practices
→ XML Schema representation of Audubon Core
→ RDF representation of Audubon Core
→ MediaWiki Help
Contents |
Add new defect topics or comment on existing ones here
1 No Container
v0.9 lacked a container for multiple records, whether of the same resource or not. This is addressed in the subversion tree revision 1586, also zipped here as File:Trunk XML 1586.zip --BobMorris 06:28, 1 March 2010 (CET)
2 Minor Namespace Botches
v0.9 had a few namespace errors. This is addressed in the subversion tree revision 1586, also zipped here as File:Trunk XML 1586.zip--BobMorris 06:28, 1 March 2010 (CET)
3 No Sample Document
v0.9 lacked a sample XML document. This is addressed in subversion tree revision 1587 also zipped here as File:Mrtg094Inst 1587.xml --BobMorris 06:28, 1 March 2010 (CET)
4 Lacks Structure for mrtg:serviceAccessPoint
v0.9 lacks a structuring element for service access point properties. As released, there is no robust way to associate the properties with a particular access point. The sample file File:Trunk XML 1586.zip addresses this by putting the metadata for the best quality image in the main record, and making a second record with the same resource identifier, but having a thumbnail service access point described. The disadvantage of this approach is that the six mandatory records must be repeated, even though they are the same as the first record. Probably a serviceAccessPoint container is the appropriate solution. --BobMorris 06:28, 1 March 2010 (CET)
- I have to confess that I don't understand this. In the XML example, the <mrtg:hasServiceAccessPoint> element is essentially being used in the same way as the <mrtg:variant> element. From my reading of the description of the Service Access Class in the schema, I would have expected that as a term for a class, hasServiceAccessPoint would be a container element nested within the record element. I realize that this makes a record no longer be "flat", but it seems to me that there is no getting around that as long as one has multiple variants for the same image (i.e. with the image conceptually being a resource that is independent of the particular variant representation). If there is going to be a separate record for each service access point, then it seems distasteful to me for the records for the different service access points to have the same dcterms:identifier. I realize that if it is not demanded that dcterms:identifier be a globally unique identifier, maybe one can get away with this, but it doesn't seem like the right approach.Steve Baskauf 20:36, 25 May 2010 (CEST)
5 Core vs. Extended Vocabularies
Most of the geolocation elements that are in the Extended layer probably belong in the Core. However, that is an issue for Discussable v0.9 normative document. The sample File:Mrtg094Inst 1587.xml did not represent the Iptc4xmpExt:City because the sample tried to stay in the Core layer. --BobMorris 06:28, 1 March 2010 (CET)
I wonder if the distinction of Core vs Extended Layer is useful at all. Maybe applications just trap and ignore the elements they can't handle. Is that too much to ask of applications? --BobMorris 06:49, 1 March 2010 (CET)
6 DateTime
In the sample File:Trunk XML 1586.zip I omitted some items with ISO 8601 DateTime records, because the parser I was using claimed they had no timezone. I wonder how much irregularity there is about 8601 parsing and validation there is and whether this will bite applications. --BobMorris 06:28, 1 March 2010 (CET)
7 Order of Elements
In email, Steve Baskauf has observed that we need to reconsider the order of MRTG use of DwC and DC elements or make them order independent. Otherwise, someone importing from DwC may face a mrtg schema invalidity. --BobMorris 14:33, 1 March 2010 (CET)
- DwC SimpleSchema has a lot of xsd:all in it, which restricts to at most once occurrence to avoid particle lookahead(?). I suspect we can't avoid a complicated representation of order independence for our repeatable elements. --BobMorris 14:33, 1 March 2010 (CET)
