Data Provenance (DPS) TC

 View Only
  • 1.  Opinions desired on CamelCase vs kebab-case

    Posted 05-03-2025 10:11

    We are currently stuck on the motion to create the work products directory in the GitHub repo. Some of the discussion is occurring on GitHub so I'm repeating it here and asking for the opinion of others. My PR#8 uses CamelCase. Stephan has a blocking review requesting change to kebab-case. I believe it's more a style issue than a technical issue (but it can be argued differently). I believe this because the directory and filenames won't be in code (software or html) to my knowledge. I've always used CamelCase because I was a software developer and that crowd prefers CamelCase because hypens are subtraction and confuse java or javascript. as well as makes it longer with extra characters. The HTML crowd prefers kebab-cases since URLs are case-insensitive (personally I like CamelCase for that reason and just don't have two filenamess that only differ by case). 

    The root issues is to not include spaces in filenames because of issues with software and operating systems. Both solve the problem. Since the vote is currently 1 to 1, I'm sending this email to see what others think.  I wouldn't fall on my sword if everyone else prefers kebab-case, but I also don't want to do the work to make the change if it's only Stefan than prefers kebab-case. 

    Whichever we decide, we should decide, make it a rule, and move on to actually doing the work.



    ------------------------------
    Duncan Sparrell
    Chief Cyber Curmudgeion
    sFractal Consulting LLC
    Oakton VA
    703-828-8646
    ------------------------------


  • 2.  RE: Opinions desired on CamelCase vs kebab-case

    Posted 05-03-2025 11:12
    Dear members,

    On Sat, May 3, 2025, at 16:10, Duncan Sparrell via OASIS wrote:
    > We are currently stuck on the motion to create the work products directory in the GitHub repo. Some of the discussion is occurring on GitHub so I'm repeating it here and asking for the opinion of others. My PR#8 <https: github.com oasis-tcs dps pull 8> uses CamelCase. Stephan has a blocking review requesting change to kebab-case. I believe it's more a style issue than a technical issue (but it can be argued differently). I believe this because the directory and filenames won't be in code (software or html) to my knowledge. I've always used CamelCase because I was a software developer and that crowd prefers CamelCase because hypens are subtraction and confuse java or javascript. as well as makes it longer with extra characters. The HTML crowd prefers kebab-cases since URLs are case-insensitive (personally I like CamelCase for that reason and just don't have two filenamess that only differ by case).
    >
    > The root issues is to not include spaces in filenames because of issues with software and operating systems. Both solve the problem. Since the vote is currently 1 to 1, I'm sending this email to see what others think. I wouldn't fall on my sword if everyone else prefers kebab-case, but I also don't want to do the work to make the change if it's only Stefan than prefers kebab-case.
    >
    > Whichever we decide, we should decide, make it a rule, and move on to actually doing the work.
    >
    > Duncan Sparrell [...]

    maybe I cannot join the call on Tuesday, so I also support the discussion
    here. First, as a general remark: I think we have plenty of time, believe me.
    I sense that there is more rush than usually sustainable over the life span
    of a TC. Having that out of the way, here comes my praise for kebab-case.

    0) we are creating a structure for things that will not be directly
    imported in programming languages that have problems with dashes.

    1) two very far-spread operating systems lie about case. You ask them for
    SomeFunnyMultiWordThing (PascalCase, not camelCase by the way) and these
    (in the default settings) will happily yield any available case variation
    they find, like somefunnymultiwordthing or SOMEFUNNYMULTIWORDTHING.
    There on Windows or Mac, when you create a someFunnyMultiWordThing (camelCase)
    it will take that case you typed, note somewhere, and next time you ask,
    git will happily send it out as exactly that case-mix upwards to the repository.
    Now you have two objects: SomeFunnyMultiWordThing and someFunnyMultiWordThing.

    2) we live in a world of single line text-input and text-display fields,
    e.g. the browser address-field or some form text-input field where
    snake_case loses the underscore a bit visually while kebab-case is clear.

    3) as soon as we get a resource from a web-server, normally case is
    significant and prone to failures in the path part of the URL.
    So, using all lower-case characters is easing the user experience.
    To still separate words and remove ambiguity, you add a dash, done.

    4) artifical ways to glue multi-word terms together require a strong
    convention and have to provide real benefit, which we do not have
    in mostly web-consumed directory-trees.

    5) in human languages that allow multi-word constructs, using a dash
    as hyphen is often a safe choice.

    6) in case we want to place acronyms into file-paths it is clear
    to everyone how this will read, like json-examples, while in
    the GluedTogether worlds you may have jsonExamples, JsonExamples,
    JSONExamples, or jSONExamples, which nicely leads to inconsistency
    and frustration.

    Sorry, for the zero-based counting, but I wanted to emphasize the
    freedom from say python import rules we have here.


    PS: I will have to exchange the hardware I use to connect to
    the world on Tuesday afternoon Swiss time, which is why I may
    not be able to join our call, for purely technical reasons.

    Cheers,
    Stefan.




  • 3.  RE: Opinions desired on CamelCase vs kebab-case

    Posted 05-03-2025 12:02

    here is an article people may want to read for background: https://www.freecodecamp.org/news/snake-case-vs-camel-case-vs-pascal-case-vs-kebab-case-whats-the-difference/

    I didn't even realize I was using PascalCase for Folder names (I thought it was camel case and I capitalized since I prefer to capitalize folder names and lower case case for file names so I can tell them apart and some OS sort that way.

    Note we can always change it later, albeit the later we wait the more effort to change. 

    I'd really welcome input from others to break our tie. And I'd really like to resolve it by the meeting at the latest so we don't wait another month until we can start actual drafting text to agree to. Did D&TA have any "style guide" or "conventions" on file or folder names?



    ------------------------------
    Duncan Sparrell
    Chief Cyber Curmudgeion
    sFractal Consulting LLC
    Oakton VA
    703-828-8646
    ------------------------------



  • 4.  RE: Opinions desired on CamelCase vs kebab-case

    Posted 05-03-2025 13:27

    Hello,

    D&TA does not have a formal style guide or set of file or folder naming conventions. So there's no guidance from that front to inform this decision.

    Speaking personally (not in my D&TA role), I support adopting kebab-case for file and folder names. In addition to the points already raised, many development and content collaboration tools (from CLI to cloud file browsers) handle kebab-case more predictably than mixed-case formats. It will reduce the risk of subtle issues related to case-sensitivity, especially when collaborating across systems. Kebab-case is also easier to read and type for participants who are not coming from a programming background.  Also worth noting is that kebab-case changes tend to be more obvious and less error-prone in diffs and merges (renaming files due to case changes alone can sometimes confuse Git and complicate version control history.

    I agree that whichever format we adopt, we should document it and move forward to the work at hand.

    Kristina

     






  • 5.  RE: Opinions desired on CamelCase vs kebab-case

    Posted 05-05-2025 13:35

    I changed the PR for work products to be kebab-case. We can approve at meeting.



    ------------------------------
    Duncan Sparrell
    Chief Cyber Curmudgeion
    sFractal Consulting LLC
    Oakton VA
    703-828-8646
    ------------------------------



  • 6.  RE: Opinions desired on CamelCase vs kebab-case

    Posted 05-05-2025 20:14

    The codecamp background paper describes what they are, but not why they should be used.  Because Windows filenames and URLs are not case-sensitive while Linux/Mac filenames are, using mixed case for directory and filenames could potentially be an issue, so I agree with kebab-case for files and directories.

    Schemas are a different issue - PR#10 is now ready to merge into the contributions area, and because the D&TA JSON Schema uses kebab-case property names the IM currently follows suit.  But because minus is an operator and can't be used in variable names, I recommend changing property names in the committee spec to snake_case or camelCase. 



    ------------------------------
    David Kemp
    National Security Agency
    ------------------------------



  • 7.  RE: Opinions desired on CamelCase vs kebab-case

    Posted 05-06-2025 11:46
    Dear members,

    On Tue, May 6, 2025, at 02:14, David Kemp via OASIS wrote:
    > The codecamp background paper describes what they are, but not why they should be used. Because Windows filenames and URLs are not case-sensitive while Linux/Mac filenames are, using mixed case for directory and filenames could potentially be an issue, so I agree with *kebab-case* for files and directories.
    >
    > Schemas are a different issue - PR#10 <https: github.com oasis-tcs dps pull 10> is now ready to merge into the contributions area, and because the D&TA JSON Schema uses kebab-case property names the IM currently follows suit. But because minus is an operator and can't be used in variable names, I recommend changing property names in the committee spec to *snake_case* or *camelCase.*
    >
    > David Kemp
    > National Security Agency [...]

    I did not spot kebab-case names in the schema derivate in the PR #10,
    but some mix of Words-on-Sticks - but I may have looked in the wrong places.

    Let me add the following perspective to information modeling:

    TL;DR; let us name concepts (keys and types in the general grammar
    a.k.a. information model) like data-provenance as kebab-case
    terms and let generators and what-not-mappers worry about
    the validity of symbols in the target language of implementations.


    Details:

    Modeling information instead of a specific data serialization
    should add value in separating concepts from implementations.

    To me the use of the most canaonical form of building multi-word
    terms is the kebab-case.

    In my experience, enforcing a mapping between such terms (keys)
    in the one governing information model and in derived specific
    models helps the iomplementers to stick with the public API
    so to say. At the same time it remains as clear as possible
    in naming the concepts and avoiding dialects of one or the other
    cult of circumvent_bad_parsers_by_working_around_space_sepataion
    or circumventBadParsersByWorkingAroundSpaceSeparation atrocities.

    The made up term exotic-word-combination is generic, could be used
    in English prose and requires mapping to syntactic valid programming language
    identifiers, not because for some the dash is a minus and thus an operator,
    no, but because programming languages never coordinated their
    opinions on what is such an identifier. In python it is snake_case
    and kebab-case cannot be valid. In css, it is kebab-case and it cannot
    be snake_case. In C++ it was camelCase and is more and more snake_case,
    and for readers all these other gluedTogetherVariants
    look artificial, hard to penetrate (separate the underlying words),
    and these camps could never agree on what to do with acronyms as
    part of such identifiers.
    Go likes to keepURIsAsTheyShould, in other languages and
    environments it is changedUrisAsNoOneRecognizesAnymore.

    Also in ABNF grammars (https://www.rfc-editor.org/rfc/rfc5234)
    you have defined-as and char-lines et al. as left hand sides of
    productions. Close to the prose so to say.

    We use generators to derive compliant impementations.


    Cheers,
    Stefan.