<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!
}
-
Is there a canonical way of representing booleans in XML?
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?
-
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
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_FOUNDIn this context, you might enjoy
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
-
Depends. Do you want your default value to be false?
Well now you're just ruining a good CodeSOD down the line.
-
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.
-
-
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.
-
@gleemonk said:
Software Development: Where the least bad option is the best option.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.
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.
-
I've seen 0/1 used. I think it's probably the least bad option.
true
andfalse
are the least bad option.1
and0
are numbers, and booleans are not numbers.true
andfalse
are explicit. Is1
the boolean true value, or is0
? After all, in C,1 && 1
is true, but in shell scripting, truthiness is defined by a zero return code. Using1
and0
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
- some fucknugget generating this horrible satan's excrement assmues that
-
We're not going to wander into the 0 indexed lists flame war again are we?
*EDIT should probably say I agree with you.
-
@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/> -->
?
-
-
@Zecc said:
Christ another humorless fucker. I'm trying to set the groundwork for a future CodeSOD and you're fucking ruining it.@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/> -->
?
-
-
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).
-
Oh, come now. I think either of my suggestions would be hilarious. Not exactly "good", but funny.
You're not quite the worst of the worst but getting there ={DJust imagine opening the sample ApacheConfig.xml and seeing dozens of options that could be set, but commented out (individually).
-
1 and 0 are numbers, and booleans are not numbers.
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...
-
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>
-
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....
-
-
@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:
there's over 1600 columns
is TR.
Well, that, and using XML to dump a recordset in the first place. An SQL export would've been a whole lot simpler.
-
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.)
-
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 valueerrno
and somehow flag that the they have done so by returning a nonsense value.However...
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.