FIXTradingCommunity / tablature

Easy authoring for rules of engagement using markdown
https://www.fixtrading.org/
Apache License 2.0
11 stars 8 forks source link

[md2orchestra] Invalid usage of dcterms name space in metadata element #62

Open JThoennes opened 2 years ago

JThoennes commented 2 years ago

Comparing the output of md2orchestra to the Orchestra file of FIX Latest, I see some notable differences: While the Orchestra FIX Latest only uses the dc: XML name space, the generated XML code uses dcterms: which causes validation errors in my IDE.

I think that the <fixr:metadata> elements only allows <dc:*>. The Orchestra FIX Latest adheres to this restriction:

<?xml version="1.0" encoding="UTF-8"?>
<fixr:repository xmlns:dc="http://purl.org/dc/elements/1.1/"
                 xmlns:fixr="http://fixprotocol.io/2020/orchestra/repository"
                 xmlns:xs="http://www.w3.org/2001/XMLSchema"
                 name="FIX.Latest"
                 version="FIX.Latest_EP269">
   <fixr:metadata>
      <dc:title>Orchestra</dc:title>
      <dc:creator>unified2orchestra.xslt script</dc:creator>
      <dc:publisher>FIX Trading Community</dc:publisher>
      <dc:date>2021-08-14T22:38:48.950856Z</dc:date>
      <dc:format>Orchestra schema</dc:format>
      <dc:source>FIX Unified Repository</dc:source>
      <dc:rights>Copyright (c) FIX Protocol Ltd. All Rights Reserved.</dc:rights>
   </fixr:metadata>

while the generated code looks like:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<fixr:repository xmlns:dc="http://purl.org/dc/elements/1.1/"
                 xmlns:dcterms="http://purl.org/dc/terms/"
                 xmlns:fixr="http://fixprotocol.io/2020/orchestra/repository"
                 name="Rules of Engagement of the FIX Trading Adapter 1.0 1.0"
                 version="1.0">
    <fixr:metadata>
        <dcterms:title>Rules of Engagement of the FIX Trading Adapter</dcterms:title>
        <dcterms:creator>Jörg Thönnes</dcterms:creator>
        <dcterms:publisher>aixigo AG, Aachen, Germany</dcterms:publisher>
        <dcterms:language>English</dcterms:language>
        <dcterms:source>aixigo-fix-orchestra.xml</dcterms:source>
        <dcterms:rights>Copyright (C) 2022, aixigo AG, Aachen, Germany</dcterms:rights>
    </fixr:metadata>

I think the problem is the Tablature RepositoryMapper.getPreferredPrefix(). The dcterms case should be removed. Then both the XML name space declaration is dropped and the dc: prefix is used.

JThoennes commented 2 years ago

@donmendelson Do you think I am correct here? Do I missing something?

donmendelson commented 2 years ago

The Dublin Core XML namespaces are a bit confusing.

dc.xsd has target namespace "http://purl.org/dc/elements/1.1/" dcterms.xsd has target namespace "http://purl.org/dc/terms/". But it also imports dc.xsd.

Therefore, many of the terms, such as subject can be valid in both namespaces.

JThoennes commented 2 years ago

So I wonder why the official Orchestra FIX Latest XML does use the other way? In addition, my IDE complains about the dcterms: usage so I would prefer to have it in one common way.

donmendelson commented 2 years ago

A bit more detail on namespaces:

A complete explanation of Dublin Core Terms Initiative namespaces is here: Namespace Policy for the Dublin Core™ Metadata Initiative (DCMI)

In short...

Therefore only http://purl.org/dc/terms/ should be necessary for our purposes.

donmendelson commented 2 years ago

The Orchestra repository schema defines metadata element like this;

<xs:element name="metadata" type="dcterms:elementOrRefinementContainer"/>

and the dcterms namespace is defined like this:

xmlns:dcterms="http://purl.org/dc/terms/"

Therefore, I believe the repository schema is using the correct namespace.

The FIX Latest file (EP 272) in the orchestrations repository also defines the namespace as

xmlns:dcterms="http://purl.org/dc/terms/"

This is also correct.

@JThoennes, the file you referred to was produced by a different process (XSLT) while starting with EP272 we started publishing a file produced with a Python script. In short, I believe that the problem has been resolved, at least in this instance.

Nevertheless, we need to examine how other tools that write Orchestra files are managing namespaces. This has always been one of the tricky aspects of XML schema usage, and I thank you for bringing it to our attention.

donmendelson commented 2 years ago

One last comment on namespaces: when an XML namespace is declared in an XML file with xmlns, only the URI following the equal sign has universal significance. The prefix before the equal sign is an alias for the namespace that has scope only for that XML file. Therefore, a different prefix can be used, but the only thing that really matters is that it points to the correct URI.

JThoennes commented 2 years ago

Thanks, @donmendelson, for your detailed answer! Did not visit this space for a while.