Closed fxprunayre closed 3 weeks ago
Not an XML issue
https://github.com/ISO-TC211/XML/pull/159#issuecomment-2448732436 - but this one is a bug fix, not an enhancement.
Raises the question of who (resource) overseas those XSLTs?
AgreedXMG should be responsibleNow we just need to identify an XSLt specialist I’ve been calling for one these last two years.The review of 19115-1 will need XSLtsEvert Bleys4 Tudor PlaceHUGHES ACTAustraliaMob: 0411 483 876On 31 Oct 2024, at 21:31, Peter Parslow @.***> wrote:
Raises the question of who (resource) overseas those XSLTs?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you modified the open/close state.Message ID: @.***>
But who owns Metadata101?It does not seem to be XMG’sEvert Bleys4 Tudor PlaceHUGHES ACTAustraliaMob: 0411 483 876On 31 Oct 2024, at 21:31, Peter Parslow @.***> wrote:
Raises the question of who (resource) overseas those XSLTs?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you modified the open/close state.Message ID: @.***>
Assuming by "Metadata101" you mean the ISO 19115 multi-part standard, that sits mostly with WG7. WG6 retain responsibility for -2.. So 19115-2 sits with WG1. Perhaps oddly, ISO 19139 sits with WG1 (as it is one of the standards that ISO 19115 and others use to inform their UML-XML mapping)
I would see those WGs being responsible for any enhancements to their standards.
But this seems more of a bug fix, akin to bug fixes in the XML schemas themselves.
Perhaps the combined "MG" meeting should confirm whether maintaining XSLTs is part of XMG's responsibility, but I can't think who else could have the skills.
I refer to metadata101/iso19115-3#27 XMG has the logical responsibility for XSLtsEvert Bleys4 Tudor PlaceHUGHES ACTAustraliaMob: 0411 483 876On 1 Nov 2024, at 22:43, Peter Parslow @.***> wrote: Assuming by "Metadata101" you mean the ISO 19115 multi-part standard, that sits mostly with WG7. WG6 retain responsibility for -2.. So 19115-2 sits with WG1. Perhaps oddly, ISO 19139 sits with WG1 (as it is one of the standards that ISO 19115 and others use to inform their UML-XML mapping) I would see those WGs being responsible for any enhancements to their standards. But this seems more of a bug fix, akin to bug fixes in the XML schemas themselves. Perhaps the combined "MG" meeting should confirm whether maintaining XSLTs is part of XMG's responsibility, but I can't think who else could have the skills.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you modified the open/close state.Message ID: @.***>
For information, I'm mainly backporting here changes we are making in the GeoNetwork XSLT conversion for ISO19139 to/from ISO19115-3 (which originates from this repository). See https://github.com/geonetwork/core-geonetwork/tree/main/schemas/iso19115-3.2018/src/main/plugin/iso19115-3.2018/convert/ISO19139
eg. spatialRepresentationType cardinality is 0..unbounded and if more than one instance is defined in the input record, the conversion fails with:
Fix by looping on all codeListValue attribute matches.
Reported here https://github.com/metadata101/iso19115-3/issues/27