Code Monkey home page Code Monkey logo

Comments (4)

helrond avatar helrond commented on July 16, 2024 1

To me I would favor consistency first and foremost in a library, so would lean towards #1. If this is how the library behaves in other circumstances, it feels like it would be confusing for this one instance to behave differently. I get that it's a "larger" change, but it also feels like we're fixing something that was broken (even though we didn't realize it until now) so it's also a necessary fix.

from iiif-prezi3.

digitaldogsbody avatar digitaldogsbody commented on July 16, 2024

My personal position is we should adopt 1 or 2, but I can't decide which I prefer.

In favour of 1 - We already require other non-optional fields to be set at instantiation (even if we let the AutoHelpers deal with setting some of them and the user doesn't necessarily explicitly have to), so why should HWD be any different? Yes it's slightly inconvenient to change existing behaviour, but it's to fix a mistake (and we have also technically done this before because the latest skeleton introduced the regexp constraints of label languages, which was technically breaking)

In favour of 2 - Outputting the JSON is the only time the data actually needs to be correct, and saving validation until then might make the library slightly friendlier to work with / more flexible in allowing the user to use the workflow best for them - maybe they don't have the HWD (or label, or etc etc) available at object instantiation, but as long as they supply it before outputting JSON, why do we care?

from iiif-prezi3.

digitaldogsbody avatar digitaldogsbody commented on July 16, 2024

@iiif-prezi/prezi3-maintainers Any other thoughts on this? I'd like to do a bit more work on the library over the next week (in expectation that a few more people might look at it after the conference), so it would be good to get this resolved.

from iiif-prezi3.

giacomomarchioro avatar giacomomarchioro commented on July 16, 2024

I agree with Hillel but in my opinion doing a post validation would be much more flexible and could also overcome some limitations of the JSON schema. I wanted to add a validation step before generating the JSON also to my library in particular for testing disjoint behaviours where you need to know where is your object to understand if the behaviour is correct.

from iiif-prezi3.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.