4 ms·
That was not quite my point. Why pretend it is a string at all? <Task> <ID>3</ID> </Task> I should have been more clear. Sometimes you have these argument t
by 616c 10y ago
That was not quite my point.
Why pretend it is a string at all?
<Task>
<ID>3</ID>
</Task>
I should have been more clear. Sometimes you have these argument type deals <Task ID="3"> where I would at least hope for <Task ID=3> or the monstrosity above (I assume ID=3 is not valid in hindsight, I am getting tired just writing this all on the second pass even!). And I see all different variations in the same XML file! There is no logical consistency, not even in the same config for the same function of this multi-stage system.
I am not even a novice programmer, and I find the variation annoying, and sometimes hard to reason about when I want to know what the hell the programer was thinking.
The valid part for the CDATA portion has changed several times in minor releases, so when our server team upgrades, I get to figure out the new syntax.
I thought XML was proposed to avoid these things! Haha. Again, tools in the hands of "wise men" like me are dangerous. I am probably as ignorant as them, I just think I know better!
- ams6110 10y agoXML as a config file format was a disaster in every example I ever encountered. Config files are supposed to be editable by humans using editors, and most that I saw were too complex for that. In particular the NeXT/Apple property file formats are horrible abuses of XML. As a format to represent structured data, it could be fine as long as you were pragmatic about it. In the case of <task id="3"> you either assumed that "id" was always an integer or you validated it with a schema declaration, which quickly got hairy. In practice I never validated XML beyond it being well-formed (which was provided by default in any parser) and never had any real problems.
- chiph 10y agoOh, this is the difference between attribute-oriented XML, element-oriented XML, and whatever-the-hell-we-feel-like-oriented XML. Publishers should pick one of the first two and be consistent about it.
- ams6110 10y agoAgree. Practical/pragmatic use of XML as a data format requires consistency.
- thangalin 10y agoWhat takes fewer lines of code to parse? <element.name id.value="3.14"> Or accepting both: <element.name id.value="3.14"> <element.name id.value=3.14> How would you specify an empty value for mandatory attributes?
- colejohnson66 10y agoI've seen empty values written as <tag attr1 attr2="val">data</tag> Whether that's legal or not, I don't know.
- oceanswave 10y agonot valid. wondering if you've seen that within HTML, where it is valid.
- colejohnson66 10y agoActually, now that you mention it, I think it's from Chrome's Inspect Element tool, but I can't check right now. I think if you wrote something like <div class="">...</div> it would display in the tool as <div class>...</div>
- kozak 10y agoChrome's Inspect Element shows you the non-serialized DOM structure, which means it's neither XML nor HTML at that point.
- oceanswave 10y agoEnclosing the attribute within double quotes isn't pre-disposing the value to be of a particular type. It's part of the XML spec that attribute values are contained within double quotes, and must be to be valid. The type isn't implied in the file. An xml schema such as <xs:element name="Task"> <xs:complexType> <xs:attribute name="ID" type="xs:int" use="required" /> </xs:complexType> </xs:element> could more explicitly declare the type of the value.
- 616c 10y agoThanks for the explanation. I guess in this case I learned be careful what you wish for. I guess this is why I prefer the <Item> <Parameter><Data></Parameter> </Item> But this is my ignorance of XML and familiarity with HTML showing.
- popmystack 10y ago>Why pretend it is a string at all? You are confusing the language and underlying datatypes, which is extremely ironic given the criticisms levied against XML in this thread.