<Xml>True</Xml>



  • This is clear and self-documenting XML:

    <DisabledAccess>True</DisabledAccess>
    <DisabledAccessComment>test</DisabledAccessComment>
    <FreeParking>False</FreeParking>
    <FreeParkingComment/>
    

    But encoding booleans as "True"/"False" string seems wrong. Is there a canonical way of representing booleans in XML? I might actually be able to influence the format. Though ... well maybe I'm just gonna suck it up.

    <OtherInformation>
          <InformationName/>
          <InformationName/>
          <InformationName/>
          <InformationName/>
          <InformationName/>
          <InformationName/>
          <InformationName>WIFI</InformationName>
    </OtherInformation>
    

    In my experience dealing with such output is easier than dealing with the people whose code generates such output.



  • IIRC in XML a boolean should be either 'true' or 'false' in lower case. I think 1 and 0 are also acceptable, but 'True' and 'False' is technically wrong.

    That's assuming you have those fields defined as an actual boolean and not just a random text field...



  • Ohhhhhhhhh how about you test for the existence of the tag to determine if a flag is set. Then later down the line you can have this code

    Boolean flag = getFlag();
    if(flag != null && flag.booleanValue() == false){
    // this is really retarded!
    }



  • @gleemonk said:

    Is there a canonical way of representing booleans in XML?

    @DogsB said:

    Ohhhhhhhhh how about you test for the existence of the tag to determine if a flag is set. Then later down the line you can have this code

    Depends. Do you want your default value to be false?



  • @Nocha said:

    technically wrong.

    Oh good. This actually helps me a lot when reading their XML. Now i feel a little dirty and complicit. The best mode to get things done quickly šŸ˜ƒ

    @Nocha said:

    That's assuming you have those fields defined as an actual boolean and not just a random text field...

    You're assuming we negotiated a schema first!? I got one example file tossed over the wall after begging for months. If I asked whether they have a DTD, this would be the answer:

    ā˜ True
    ā˜ False
    ā˜‘ FILE_NOT_FOUND

    In this context, you might enjoy

    <?xml version="1.0" encoding="utf-8" standalone="yes"?>


  • @Zecc said:

    Depends. Do you want your default value to be false?
    Well now you're just ruining a good CodeSOD down the line.



  • @DogsB said:

    Boolean flag = getFlag();
    if(flag != null && flag.booleanValue() == false){
    // this is really retarded!
    }

    I copy patern to all places were apply. Thank you for help.



  • Or borrow <true/> and <false/> elements from Property Lists.



  • @wft said:

    Property Lists

    Burn it with fire.


  • Discourse touched me in a no-no place

    @gleemonk said:

    Is there a canonical way of representing booleans in XML?

    I've seen 0/1 used. I think it's probably the least bad option.



  • @FrostCat said:

    @gleemonk said:
    Is there a canonical way of representing booleans in XML?

    I've seen 0/1 used. I think it's probably the least bad option.

    Software Development: Where the least bad option is the best option.

    I think the thing that really broke me as a software developer is when I first implemented code that while retarded was less retarded than the other suggestions.



  • @FrostCat said:

    I've seen 0/1 used. I think it's probably the least bad option.

    true and false are the least bad option. 1 and 0 are numbers, and booleans are not numbers. true and false are explicit. Is 1 the boolean true value, or is 0? After all, in C, 1 && 1 is true, but in shell scripting, truthiness is defined by a zero return code. Using 1 and 0 also has a non-zero probability, asymptotically approaching 1 as time increases, that either:

    • some fucknugget generating this horrible satan's excrement assmues that not 0 == true and they can therefore dump any old crap in there.
    • another fucknugget receiving said atrocity assuming not 0 == true and blindly accepts any old crap, thus ignoring batantly obvious bugs


  • We're not going to wander into the 0 indexed lists flame war again are we?

    *EDIT should probably say I agree with you.



  • @Zecc said:

    @DogsB said:
    Ohhhhhhhhh how about you test for the existence of the tag to determine if a flag is set. Then later down the line you can have this code

    Depends. Do you want your default value to be false?

    Also, how do you indicate that an option exists when it's false? A giant readme.rtf?

    <!-- enable access <DisableAccess/> --> ?


  • BINNED

    @anotherusername said:

    A giant readme.rwtf?

    FTFY



  • @anotherusername said:

    @Zecc said:
    @DogsB said:
    Ohhhhhhhhh how about you test for the existence of the tag to determine if a flag is set. Then later down the line you can have this code

    Depends. Do you want your default value to be false?

    Also, how do you indicate that an option exists when it's false? A giant readme.rtf?

    <!-- enable access <DisableAccess/> --> ?

    Christ another humorless fucker. I'm trying to set the groundwork for a future CodeSOD and you're fucking ruining it.



  • @DogsB said:

    Christ another humorless fucker.

    YMBNH.



  • Oh, come now. I think either of my suggestions would be hilarious. Not exactly "good", but funny.

    Just imagine opening the sample ApacheConfig.xml and seeing dozens of options that could be set, but commented out (individually).



  • @anotherusername said:

    Oh, come now. I think either of my suggestions would be hilarious. Not exactly "good", but funny.

    Just imagine opening the sample ApacheConfig.xml and seeing dozens of options that could be set, but commented out (individually).

    You're not quite the worst of the worst but getting there ={D



  • @tufty said:

    1 and 0 are numbers, and booleans are not numbers.

    @tufty said:

    After all, in C, 1 && 1 is true, but in shell scripting, truthiness is defined by a zero return code.

    You just explained why booleans are not numbers, then you bring up numerical return codes as if they were booleans...


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.