gmantele / ucidy Goto Github PK

When packaging ucidy with other libraries, it's a bit untidy to have the resource text files ucd1p-words.txt, ucd1p-deprecated.txt at the top level of the namespace. Any chance of moving them to ari/ucidy/?

@gmantele, I'm trying to write a function that reports a single category for a presented UCD. My current attempt looks like this:

        UCD pucd = UCDParser.parseUCD( ucd );
        if ( ! pucd.isAllValid() ) {
            return "BAD_SYNTAX";
        }
        else if ( ! pucd.isAllRecognised() ) {
            return "UNKNOWN_ATOM";
        }
        else if ( ! pucd.isFullyValid() ) {
            return "BAD_SEQUENCE";
        }
        else if ( ! pucd.isAllRecommended() ) {
            return "DEPRECATED";
        }
        else {
            return "OK";
        }

However, it's not doing what I want. In particular it never seems to report DEPRECATED, because deprecated words are flagged as not recognised as well as not recommended, which is not what I expected from the UCDWord javadocs:

jshell> UCDParser.parseUCD("time.expo").isAllRecognised();
$27 ==> false

jshell> UCDParser.parseUCD("time.expo").getErrors().next();
$28 ==> "1 DEPRECATED UCD word: \"time.expo (-> time.duration;obs.exposure)\"!"

Can you advise? Thanks.

Feature request: it would be nice if UCDParser instances could report what version of the UCDList standard (i.e. what word lists) they implement, e.g. if UCDParser.defaultParser.getVersion() could return "EN-UCD1+-1.4" or "EN-UCD1+-1.4 with Erratum 1" or similar. Obviously that information would have to be supplied at UCDParser construction time.

@gmantele, is there a good reason that the UCDParser.defaultParser instance is declared with scope protected? It makes it complicated to work with custom UCDParser instances, e.g. to get a copy of the default word list (though not impossible, you can get access to the member by subclassing UCDParser). If there's not a good reason, could it be promoted to public?

See http://www.ivoa.net/documents/UCD1+/20180527/REC-UCDlist-1.3-20180527.pdf

@gmantele, now that UCDlist 1.4 is (officially?) accepted, will you be issuing a matching Ucidy update? And/or would you like a contributed PR to do that?

For library (as opposed to standalone) use, it's a bit annoying to have output printed direct to stderr. In the current v1.2-beta, when the class UCDParser class is first loaded, the following text is written to stderr:

[l.212] ERROR: Skipped deprecated UCD declaration! Cause: The UCD word "meta.ref.ivorn" can not be declared as deprecated! It is already listed among the recognised UCD words.

I understand the standards issue that this is referring to, and I guess it will go away when v1.2 is finalised, but if the situation is likely to persist a nicer alternative would be to have such output e.g. sent through the java.util.logging system so it can be controlled by client applications. I can prepare a PR to do this if you like.

The manifest of the released jar file is built according to this section of the build.xml file:

     <manifest>
       <attribute name="Main-Class" value="${main.runnable.class}"/>
       <attribute name="Class-Path" value="."/>
     </manifest>

I don't know why the "." class-path entry is added here. It could present some kind of minor security issue, but the real reason I mention it is because it messes up part of my build system. I can certainly work round it if required, but if there's no good reason for its presence, could it be removed?