<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 :smiley:

    @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/> --> ?


  • :belt_onion:

    @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...



  • @DogsB said:

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

    Ummm... okay so like this:

    <Options>
      <Option1>
        <Name>DisableAccess</Name>
      </Option1>
      <Option2>
        <Name>FreeParking</Name>
      </Option2>
      <!-- ... -->
    </Options>
    <!-- ** snip 3,728 lines ** -->
    <Enable>
      <Option1>
        <Enabled>Yes</Enabled>
      </Option1>
      <Option2/>
      <!-- ... -->
    </Enable>
    

  • Impossible Mission Players - A

    @anotherusername said:

    option exists when it's false?

    This kills me every time I try to maintain compatibility between a desktop version of an app (not written by me) and the web-version. The Desktop version is apparently using its' own hand-rolled XML interpreter that explicitly requires elements to disappear when the value is false (or zero, or blank, or null).
    It also requires sub-elements to be ordered in a specific way, and that it be "pretty printed" between nodes.

    One day when my app becomes a drop-in replacement, I'm probably going to cut the backwards compatibility....


  • :belt_onion:

    @DogsB said:

    ={D

    Syntax error in line 1: Unexpected mustache



  • @anotherusername said:

    @DogsB said:
    You're not quite the worst of the worst but getting there ={D

    Ummm... okay so like this:

    <Options>
      <Option1>
        <Name>DisableAccess</Name>
      </Option1>
      <Option2>
        <Name>FreeParking</Name>
      </Option2>
      <!-- ... -->
    </Options>
    <!-- ** snip 3,728 lines ** -->
    <Enable>
      <Option1>
        <Enabled>Yes</Enabled>
      </Option1>
      <Option2/>
      <!-- ... -->
    </Enable>
    ```</blockquote>The stuff of nightmares. A real terror. Nice job fello!
    
    That last option2 will have us stumped for years to come.


  • That's how FileMaker exports in FMPXMLRESULT form.

    <METADATA>
        <FIELD EMPTYOK="YES" MAXREPEAT="1" NAME="Date" TYPE="DATE" />
        <FIELD EMPTYOK="YES" MAXREPEAT="1" NAME="Discount1" TYPE="NUMBER" />
    ...
    <RESULTSET FOUND="70">
      <ROW>
        <COL>
          <DATA></DATA>
        </COL>
        <COL>
          <DATA>81</DATA>
        </COL>
      </ROW>
    ...
    

    My export file has 70 records. It's 426032 lines and almost 8M. Oh, did I mention there's over 1600 columns...



  • That schema is bad, but actually not too outrageous. This:

    @dcon said:

    there's over 1600 columns

    is TR‌:wtf:.

    Well, that, and using XML to dump a recordset in the first place. An SQL export would've been a whole lot simpler.



  • @anotherusername said:

    Well, that, and using XML to dump a recordset in the first place. An SQL export would've been a whole lot simpler.

    Yeah, but I need to run my tool on systems that don't necessarily have FMP installed (or any database manager).

    (The FMP schema was developed by non-DB people. But it does what we need it to do.)



  • @powerlord said:

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

    No, I explained one of the reasons using numbers as booleans is a fucking bad idea, and gave two examples that illustrate the point.

    I should probably add the following line from linux's errno.h

    #define ENOENT 2 /* No such file or directory */

    If 0 is false, and 1 is true, we have our old friend troolean logic, again. true, false, FILE_NOT_FOUNDENOENT

    <belm>FILE_NOT_FOUND_OR_NULL</belm>



  • OK, let me be blunt:

    C. Error. Codes. Are. Not. Boolean.

    A program can return any non-zero number it wants for the error code. The idea was that they would return different numbers for different error conditions.



  • Let me be blunt, in turn.

    You. are. a. fucking. spastic.

    At no point have I argued that C error codes are, or should be, considered boolean. Indeed, my post above doesn't even make sense in that respect, because the return value of (for example) fopen() is not an error code, but
    @POSIX said:

    Upon successful completion, fopen() shall return a pointer to the object controlling the stream. Otherwise, a null pointer shall be returned, and errno shall be set to indicate the error.

    There you go. Most core functions, due in part C's lousy type system, have to put an error code in the global value errno and somehow flag that the they have done so by returning a nonsense value.

    However...

    @powerlord said:

    A program can return any non-zero number it wants for the error code.

    I bet you'd like to tell me why I've emphasised the "non-zero number" bit. Could it possibly be that, as C has no notion of boolean types, the following code works?

    [code]
    if (errno) {
    /* error handling */
    }
    [/code]
    Why yes, it could.

    You mong.


Log in to reply
 

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