5 ms·

I agree there's an annoying mismatch between how XML treats data and almost any programming language does. Without an XML-Schema saying otherwise (and, yuck),

• frobozz 13y ago
  This doesn't even look remotely unlike the behaviour of "almost any programming language". If you have an a set of people, do you separate them out into a "manList" and a "womanList", and then panic about having to create a "secondManList" because some men came in after the women? If order is only important within gender, then you can happily just add the men onto the end of the original manList. If it is important across all people, then you have to have a "personList". Just like you might have a "personList" that can contain "male people" and "female people", you can automatically map the whole sequence of "a elements" and "b elements" to an "elementList". In the case of mixed content (text nodes and element nodes together), you would simply map them all to a "nodeList".
  • sixbrx 13y ago
    I think you're making my point, with your inclusions of "if"'s ("If order is only important within gender") that a machine would not and generally cannot know, without understanding the semantics of the data to begin with. That's a disadvantage because that's precisely the sort of "extra metadata" that is needed to complete the XML mapping in the general case that I was talking about - it requires human intervention and therefore a custom one-off mapping, or else at least something like an XML schema [edit: more like JAXB annotations]. The Json doesn't require either of these. Also, do you really expect an automated process to do the abstraction from "female" list and "male" list to person list? That's more than just metadata that you're assuming to be in context (which was my point), but actual AI! This is very different from programming languages, where collections of things which occur within objects and structs are given names which reflect their intended meanings, like with Json.
    • frobozz 13y ago
      But it's still no different to any other language. An XML element has two collection members, one representing the attributes, and another representing the child nodes. How is this different from a Java object which contains two list members called "attributes" and "children"? How is this different from an S-Expression containing two lists? How is this different from a json object like {"attributes":[...], "children":[...]}? Bear in mind that there is no requirement for JSON lists to be homgeneous. {"things":[1,true,"hello",3,{"addressee":"world"},[{"greeting":"Hola"},7],false]} is a perfectly valid JSON object. You don't have to define it as {"numbers":[1,3], "strings":["hello"] ...}. It is a pretty common behaviour, that if you want a homogeneous list of things that differ, then you make abstractions until the differences disappear, e.g in an OO situation, you go up the inheritance tree until you are at the lowest common base class. In an XML situation, that common base class is "Node". Even in a strongly typed language that requires homogeneity in lists, the only thing you know about the list members is that they can be cast to the same type, not that the members are of that type and no other, and certainly not that they all have the same name. Consider a C++ array of CFruit objects. It may have a member that is of class CBanana, one that of class CApple, and another of class COrange. If you want to do something COrange specific with the oranges, then you have to perform dynamic_cast<COrange> on any member of that list you suspect of being an orange. The same is true in a duck-typing situation. The reason for my male & female example is that you would normally simply have a list of people. Of course, if your model contains no base that is common to both men and women, then you can't expect the machine to work that out, but if Man and Woman both inherit from Person, or if there is no Man or Woman, just Person with a member that specifies a gender, then it's trivial.