Android manifest

Bulb

It's XML. It's not well thought out by definition.

Reminds me, is with the use of namespaces Android (for a change) manifest.

Android manifests start with

<manifest xmlns:android="http://schemas.android.com/apk/res/android" …>

and then none of the tags have any namespace either, but all the attributes, with notable exception of package on the manifest element, have android: prefix. It's not like it would make sense for the manifest to contain anything else than what the Android SDK defines and it's not like the elements were derived from anything generic.

Gąska

They probably use dumbed-down custom-tailored non-conforming implementation of XML parser that's good for parsing exclusively this one thing. Which actually makes much more sense than using general-purpose XML parser.

Bulb

They include the standard XML toolchain from Java and while they have their own binary serialization format for it, they use that format for some other XML documents as well, so I don't think that would be the case.

Besides I can't see how including a namespace for all attributes except one would make any parser simpler.

Gąska

My assumption was that they try to make the XML look professional, while under the hood they search for literal <android:something somethingelse="somevalue"> and then proceed to parse the thing between > and </android:something>.

Bulb

@Gaska said:

<android:something somethingelse="somevalue">

That's exactly what it isn't. All the tags look like

<something android:somethingelse="somevalue"/>

And no, they parse it java.xml.~~sucks~~sax (or maybe some org.apache wrapper, not sure).

Gąska

@Bulb said:

That's exactly what it isn't. All the tags look like

<something android:somethingelse="somevalue"/>

Doesn't change much.

@Bulb said:

And no, they parse it java.xml.sucks (or maybe some org.apache wrapper, not sure).

Then the only explanation is that project leader has masochistic tendencies and absolute power over data formats.

Bulb

@Gaska said:

Then the only explanation is that project leader has masochistic tendencies and absolute power over data formats.

I suspect

@Gaska said:

I wonder how many people in your team knew about XML namespacing before being hired in place where they needed this knowledge. I bet that most didn't, and I bet that teaching them the concept was just as hard (or easy) as it would be to teach them a custom solution for any other format.

it's more likely he simply had some serious misconceptions about what it does and what it is useful for.

Bulb

@Gaska said:

Doesn't change much.

Yes, it does.

<android:something somethingelse="somevalue"/>

would be much less of a . It would still be , because simply starting with

<manifest xmlns="http://schemas.android.com/apk/res/android"…>

(without prefix, so applies as default to everything) would have been simpler and sufficient and therefore the non-WTF way. But putting just attributes to a namespace makes the much, much bigger.

Gąska

@Bulb said:

Yes, it does.

Not in my example. It doesn't matter if the magic constant starts with <android:something somethingelse or <something android:somethingelse.

abarker

@Bulb said:

simply starting with

<manifest xmlns="http://schemas.android.com/apk/res/android"…>

(without prefix, so applies as default to everything) would have been simpler and sufficient and therefore the non-WTF way. But putting just attributes to a namespace makes the much, much bigger.

But that isn't the same. The current version:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"…>
    <something android:somethingelse="somevalue"/>
    ...
</manifest>

Is not the same as your proposed version:

<manifest xmlns="http://schemas.android.com/apk/res/android"…>
    <something somethingelse="somevalue"/>
    ...
</manifest>

Because now instead of having two different namespaces, you have one, and you don't know if there is a reason for the two namespaces^[1] or not. If there is a reason, it's probably , but your proposed change might fuck up something that you are unaware of.

^[1] Ok, it's more like one namespace and a NULL namespace, but whatever.

Bulb

I am not saying it is the same. I am saying that it would have been the right thing to do.

abarker

@Bulb said:

I am not saying it is the same. I am saying that it would have been the right thing to do.

Unless you know why they do it using the current method, how do you know that your suggestion is the right thing to do?

Filed Nuder: Devil's avacado

Jaime

@abarker said:

Unless you know why they do it using the current method

The namespace is called "android". Either it's for all the standard Android stuff (and the implementation is the ) , or the is the name. If the namespace were "androidv2", or "androidattribs", then the current system might make some sense.

Jaime

@Gaska said:

Not in my example. It doesn't matter if the magic constant starts with <android:something somethingelse or <something android:somethingelse.

You're the guy who complains that the vendor is the problem when they publish a manifest like this:

<manifest xmlns:a="http://schemas.android.com/apk/res/android"…>
    <something a:somethingelse="somevalue"/>
    ...
</manifest>

... and your home-rolled parse mishandles it. The XML people already thought of the possibility that two add-ins might want to use the same alias - namespacing goes by the URN the alias refers to, not the actual characters before the colon.

Home grown parsers are destined to go on the front page of this site.

Gąska

Oh, I didn't realize that Android manifest is supposed to be extendable. That's so unlike everything else that I've ever encountered in my computer career that's been called a manifest.

Jaime

Where did you get the crazy notion that I believe the Android manifest is extendable? I complained that your hypothetical parser might barf on a manifest that was generate with an alternate URN alias.

Gąska

@Jaime said:

add-ins

Jaime

That's the underlying reason namespace alias work the way they do. However, an XML file doesn't have to have a need for add-ins in order to break parsers that are ignorant of this capability.

As far as I can tell, you can barely understand the conversation going on here.

Gąska

It's hard to follow when you suddenly mention add-ins where they're not relevant at all.

Anyway, my parser would break if someone used unexpected namespace for http://schemas.android.com/apk/res/android. So what? Just make them fix the damn thing. And if that's not the option, modify my parser to look for <something [A-Za-z]+:somethingelse instead.

Jaime

The point is, it's not unexpected. The namespace is http://schemas.android.com/apk/res/android, as specified in the root element. Whether they chose 'a' or 'android' for the alias doesn't change how the attributes are namespaced. Well, not to a proper parser, but a half-baked parser written by someone with a "it works" mentality will barf.

It's the parser that's broken, not the XML. If you just use standard formats and parsers, then you would never have to think about these things - they're solved problems.

@Gaska said:

It's hard to follow when you suddenly mention add-ins where they're not relevant at all.

I only mentioned add-ins to provide a justification for why the feature exists at all. The fact that you thought I was saying it is relevant to this XML is what prompted me to wonder if you understand what's going on here.

Jaime

@Gaska said:

So what? Just make them fix the damn thing. And if that's not the option, modify my parser to look for <something [A-Za-z]+:somethingelse instead.

And endless cycle of unclear specifications and misunderstandings is not what this world needs. Reinventing the wheel is bad enough, don't reinvent the square wheel.

Gąska

@Jaime said:

The point is, it's not unexpected.

Depends on what I say in Android docs.

@Jaime said:

Well, not to a proper parser, but a half-baked parser written by someone with a "it works" mentality will barf.

Idiotic requirements call for idiotic solutions.

@Jaime said:

It's the parser that's broken, not the XML.

My data format is subset of XML and is incompatible in some cases. Sue me.

@Jaime said:

If you just use standard formats and parsers, then you would never have to think about these things - they're solved problems.

It's a tradeoff between dealing with text parsing and dealing with API of the library at hand. And contrary to what you're about to say, there's no clear winner.

@Jaime said:

I only mentioned add-ins to provide a justification for why the feature exists at all.

Then you made a very bad job, because I still don't know how. What happens if I use non-existing namespace? How should I handle namespaced tags I don't recognize? How should I handle namespaced parameters I don't recognize in tags I do recognize? How should I handle non-namespaced tags and parameters I don't recognize? Is any of these actually specified in any of W3C docs?

@Jaime said:

Reinventing the wheel is bad enough, don't reinvent the square wheel.

Exactly. Use INI format goddammit. It would work exactly as well for the purposes of Android manifest.

Buddy

Redirecting to Google Groups

Is there an XML schema against which all the Android config objects
that declare the http://schemas.android.com/apk/res/android name space
can be verified against?

No, sorry. It's not even possible in many cases, since the element
names are not known at validation time

Jaime

@Gaska said:

What happens if I use non-existing namespace?

Nothing. Parsers recognize what they recognize. If you don't recognize it, then it isn't for you.

Well... unless you enforce a schema that states that nothing is allowed other that what you describe. In that case, the document doesn't parse at all.

BTW, "non-existing namespace" isn't actually a thing. Namespaces represent control, and a namespace you define is simply a string that is under your control - like a URL that points to part of your website. If you say http://gaska.com/mynamespace is a thing, then http://gaska.com/mynamespace is a thing (as long as you purport to control gaska.com). XML provides you a means to unambiguously define it, but it's up to you to communicate your intent of what it means.

@Gaska said:

How should I handle namespaced tags I don't recognize? How should I handle namespaced parameters I don't recognize in tags I do recognize? How should I handle non-namespaced tags and parameters I don't recognize? Is any of these actually specified in any of W3C docs?

All these are issue related to the content, not the format. XML successfully communicated the content to you, you are free to be confused on how to handle it. Small cars shouldn't be called useless because they can't be used for moving furniture and XML shouldn't be considered a failure because it didn't solve your extensibility problem.

@Gaska said:

My data format is subset of XML and is incompatible in some cases. Sue me.

Implementing all of XML is as simple as using one of a hundred readily-available libraries. Implementing a subset requires more effort. You are saying that doing more work to get less is a sensible strategy. I won't sue you, but I certainly wouldn't hire you.

Gąska

@Jaime said:

Nothing. Parsers recognize what they recognize. If you don't recognize it, then it isn't for you.

Just to be sure - are we speaking of parsers, the general-purpose XML libraries that translate arbitrary files in data structure for further processing, or parsers, as in complete process of extracting and interpreting data stored in file?

@Jaime said:

BTW, "non-existing namespace" isn't actually a thing. Namespaces represent control, and a namespace you define is simply a string that is under your control - like a URL that points to part of your website.

I always wondered what was under all those URLs. Turns out nothing.

@Jaime said:

If you say http://gaska.com/mynamespace is a thing, then http://gaska.com/mynamespace is a thing (as long as you purport to control gaska.com).

Anybody checks it?

@Jaime said:

All these are issue related to the content, not the format.

If so, namespaces are irrelevant to the concept of extendability. They're just one of many forms to annotate it (a ridiculously verbosy one, I must say).

@Jaime said:

Small cars shouldn't be called useless because they can't be used for moving furniture and XML shouldn't be considered a failure because it didn't solve your extensibility problem.

The problem with car analogies is like comparing a cheap customer car to an expensive sports car: they don't compare.

@Jaime said:

Implementing all of XML is as simple as using one of a hundred readily-available libraries.

Which isn't trivial. At least in C++ world where every single XML library ever made sucks balls so hard that spermatozoa explode.

@Jaime said:

Implementing a subset requires more effort.

I've once implemented a simple JSON parser in two lines. One was substring search, the other was slicing. Worked for my case. It definitely took less effort than whatever I would do using a proper library.

@Jaime said:

You are saying that doing more work to get less is a sensible strategy.

No. I'm saying that obviously wrong solutions are okay if they work and take less time (that regex thing earlier would definitely take less time than whatever eight API calls I would have to do for the same effect) and are morally justifiable if the requirements are just as wrong.

@Jaime said:

I won't sue you, but I certainly wouldn't hire you.

You don't like people criticizing your technology choices? Because the first thing I would do is to do everything in my power for the manifest to be anything more sensible than XML.

Bulb

@Jaime said:

namespacing goes by the URN

@Jaime said:

If the namespace were "androidv2", or "androidattribs"

The namespace is, therefore, obviously, called http://schemas.android.com/apk/res/android. So what do you mean by "androidv2" or "androidattribs"? The prefix is irrelevant.

And it is not wrong either; it is used in various other places in the resources. It is, however, only ever used for attributes, and only for some of them, while no tags seem to be namespaced anywhere.

@Gaska said:

Oh, I didn't realize that Android manifest is supposed to be extendable. That's so unlike everything else that I've ever encountered in my computer career that's been called a manifest.

It definitely is supposed to be extensible. It still does not explain why only attributes are namespaced and the tags are not.

@Gaska said:

Exactly. Use INI format goddammit. It would work exactly as well for the purposes of Android manifest.

In the basic form it wouldn't. And keys with multiple values and repeated sections and nested sections and such are done differently by each application that uses “ini” format (quite similar to “csv” in that regard). Hell, even the meaning of ‘key’ and ‘value’ are not uniform (most have ‘section’, ‘key’ and ‘value’, but windows make it ‘key’, ‘value’ and ‘data’ in registry and the related “ini” export format).

@Gaska said:

Which isn't trivial. At least in C++ world where every single XML library ever made sucks balls so hard that spermatozoa explode.

I, unfortunately, have to agree with you.

I would still not say that writing parser for subset of XML by hand, as long as there is any non-trivial nesting, is any easier.

Moreover, the situation is specific to C++ and processing data in C++ is masochism for many other reasons anyway. Java, C#, Python, Ruby etc. all have sensible libraries for deserializing XML to data structures, both generic and user-defined and using these is definitely easier than creating a new format (yes, they can deserialize JSON and YAML, but they are still just as easy, not easier).

marczellm

@Jaime said:

a namespace you define is simply a string that is under your control - like a URL that points to part of your website

Which is to me a biggest :WTF: about XML. Given the whole semantic notion of what XML should or could be, it freaks my brains out that a namespace is something that looks like an URL (where, maybe, I could get information about that namespace, or better, machine-readable information that the parser can utilize) but NO, the URL usually gives me a 404 and is anyway completely unrelated to anything in the XML file itself.

Buddy

@Bulb said:

It is, however, only ever used for attributes, and only for some of them, while no tags seem to be namespaced anywhere.

Which, now that I think about it, is a real rwtf, considering how easy it is to convert from java objects to schemas and back. Wtf the fuck are these guys deserializing to? Or are they climbing around in the dom tree like monkeys?

Gąska

@Bulb said:

It definitely is supposed to be extensible.

Not really.

All the elements that can appear in the manifest file are listed below in alphabetical order. These are the only legal elements; you cannot add your own elements or attributes.

@Bulb said:

In the basic form it wouldn't.

Okay. JSON then.

@Bulb said:

And keys with multiple values and repeated sections and nested sections and such are done differently by each application that uses “ini” format (quite similar to “csv” in that regard).

Is that a problem?

@Bulb said:

Hell, even the meaning of ‘key’ and ‘value’ are not uniform (most have ‘section’, ‘key’ and ‘value’, but windows make it ‘key’, ‘value’ and ‘data’ in registry and the related “ini” export format).

Has it hurt anybody?

@Bulb said:

I would still not say that writing parser for subset of XML by hand, as long as there is any non-trivial nesting, is any easier.

Agreed. The more complex the data file, the less sense it makes. And XML files tend to be insanely complex by design.

@Bulb said:

Moreover, the situation is specific to C++ and processing data in C++ is masochism for many other reasons anyway. Java, C#, Python, Ruby etc. all have sensible libraries for deserializing XML to data structures, both generic and user-defined

Might be so. If they really are that cool, I would gladly use them. Still, XML is terrible choice for this manifest file. It works, but it's terrible.

@Buddy said:

Which, now that I think about it, is a real rwtf, considering how easy it is to convert from java objects to schemas and back. Wtf the fuck are these guys deserializing to?

Okay, can someone explain to me WTF namespacing has to do with deserialization in Java? Isn't it like, "here, get this random file and parse it into nice tree, then reinterpret_cast it into some object"?

Jaime

@Gaska said:

Anybody checks it?

If you lie in your data, the tools won't try to catch you.

@Gaska said:

If so, namespaces are irrelevant to the concept of extendability. They're just one of many forms to annotate it (a ridiculously verbosy one, I must say).

They're not irrelevant. You just keep insisting that XML claims to somehow help understand content, apparently so you can bash it for not being successful at it. The problem is your understanding of what XML claims to do. It's a spec for serializing data that has specific feature designed for extensibility, but it is still up to you to implement that extensibility.

@Gaska said:

I've once implemented a simple JSON parser in two lines. One was substring search, the other was slicing. Worked for my case. It definitely took less effort than whatever I would do using a proper library.

In the languages I use, loading an XML document with a proper library takes one line of code.

Jaime

@marczellm said:

Which is to me a biggest about XML. Given the whole semantic notion of what XML should or could be, it freaks my brains out that a namespace is something that looks like an URL (where, maybe, I could get information about that namespace, or better, machine-readable information that the parser can utilize) but NO, the URL usually gives me a 404 and is anyway completely unrelated to anything in the XML file itself.

Technically, a namespace is a URN, which is a superset of URL. The idea is that every author who wants to distinguish "this bit of stuff" from "that bit of stuff" needs some signifier to do so. In order to make a convention where collisions are incredibly unlikely, XML recommends using URLs, which start with a DNS name that's given out through a set of registrars and has already solved the uniqueness problem. So, http://schemas.android.com/apk/res/android starts with http:// to signify "this URN is a URL", then schemas.android.com for "this URN belongs to the people who own schemas.android.com", then /apk/res/android as a final portion so that this group can publish multiple distinct URNs and also to provide a bit of descriptiveness.

In order to minimize confusion, some vendors go the extra step of actually putting a page that describes the schema at that URL, but there is no intention in the XML spec that any tool would ever fetch the content from that URL.

Gąska

@Jaime said:

If you lie in your data, the tools won't try to catch you.

So the "unique" and "ownership" things are pure bullshit. It works for the same reason why paper money works.

@Jaime said:

The problem is your understanding of what XML claims to do. It's a spec for serializing data that has specific feature designed for extensibility, but it is still up to you to implement that extensibility.

I still don't see how namespaces help me to achieve more extensibility than simply ignoring tags I don't understand.

@Jaime said:

In the languages I use, loading an XML document with a proper library takes one line of code.

OK, now extract that value. You have only one line left.

@Jaime said:

Technically, a namespace is a URN, which is a superset of URL. The idea is that every author who wants to distinguish "this bit of stuff" from "that bit of stuff" needs some signifier to do so.

The idea of user agent is that every browser will have distinct one.

@Jaime said:

In order to make a convention where collisions are incredibly unlikely, XML recommends using URLs, which start with a DNS name that's given out through a set of registrars and has already solved the uniqueness problem.

Can you cite some source for that?

Ragnax

@abarker said:

Ok, it's more like one namespace and a NULL namespace, but whatever.

It's more like one explicit namespace and one default namespace set to whatever the hell fallback namespace the code invoking the XML parser says it should be using, which is probably the android URN anyway.

Odds are the explicit xmlns:android namespace declaration and use of namespaced attributes is something left in for legacy reasons: for outdated software like old parts of development toolchains with lots of code rot that don't use a real XML parser when they should. E.g. using simple string find/replace for token substitution of build version numbers, instead of using a proper XML-based tool like XSLT or Microsoft's XDT (XML Document Transformation).

marczellm

Thank you for the explanation. I understand this reasoning that led to that decision, but the resulting world is a worse place to live in. I feel one flaw in the thought process though:

@Jaime said:

XML recommends using URLs, which ... have already solved the uniqueness problem

This one smells to me like "let's pick a tool made for a completely different purpose that also happen to solve our problem, and disregard its original purpose". The result is a lot of URL-s, Uniform Resource Locators that Locate no Resource, because the Resource does not exist and there is nothing at the given Location. Which confuses me to no end.

Buddy

@Gaska said:

Okay, can someone explain to me WTF namespacing has to do with deserialization in Java? Isn't it like, "here, get this random file and parse it into nice tree, then reinterpret_cast it into some object"?

Well, you can google jaxb if you want the whole story, but the bullet points are:

namespace specifies the schema
schema specifies the document structure
java classes are generated from the schema (or vice versa)
document is (de)serialized directly from/into classes

That reinterpret_cast thing doesn't sound compatible with strong typing.

Gąska

@Buddy said:

namespace specifies the schema

What specifies that a given namespace belongs to a given schema? Where does the binding between schema and namespace occur? Why would I want to have multiple schemas for a single document?

@Buddy said:

That reinterpret_cast thing doesn't sound compatible with strong typing.

That was a joke.

Buddy

@Gaska said:

What specifies that a given namespace belongs to a given schema

And is there any thing you can point to and say “this is an xsd file” the electrons that make up the bits that represent its content are constantly being drained and replenished don't you see, in a world where resources are not uniform, there can be no Uniform Resource Names?

@Gaska said:

Where does the binding between schema and namespace occur

When you serialize, you need to tell the serializer what namespace(s) to use. In jaxb, set up a serialization context by passing in the package name of your generated classes, all the information will be included as annotations on those.

@Gaska said:

Why would I want to have multiple schemas for a single document

To allow adding new element types to an existing schema (at extension points specified in the original) without breaking backward compatibility.

That was a joke

You're a joke. (This is a joke).

Gąska

@Buddy said:

And is there any thing you can point to and say “this is an xsd file” the electrons that make up the bits that represent its content are constantly being drained and replenished don't you see, in a world where resources are not uniform, there can be no Uniform Resource Names?

You missed the point. Why do I have to point the namespace at any URN if it's all meaningless and I can validate it with any XSD I want anyway?

@Buddy said:

When you serialize, you need to tell the serializer what namespace(s) to use.

If I understand correctly, nothing in my file nor in my schema tells that this file has this schema. What's the point of namespaces then?

@Buddy said:

To allow adding new element types to an existing schema (at extension points specified in the original) without breaking backward compatibility.

It can be done in other ways too. Namespace is just one way. Extremely verbose, extremely complicated way that was declared the standard. All the backwards compatibility gains you claim to come from namespaces, actually come from the tooling around XML - specifically, the agreement that every major vendor will do everything in their power that XML files will be extensible if you use namespaces and will burn in hell if you try to pull off anything else to achieve the same effect. In itself, namespaces are just very long prefixes with #defines.

Buddy

@Gaska said:

It can be done in other ways too. Namespace is just one way. Extremely verbose, extremely complicated way that was declared the standard. All the backwards compatibility gains you claim to come from namespaces, actually come from the tooling around XML - specifically, the agreement that every major vendor will do everything in their power that XML files will be extensible if you use namespaces and will burn in hell if you try to pull off anything else to achieve the same effect. In itself, namespaces are just very long prefixes with #defines.

Hey! That's what I was gonna say! Namespaces are an implementation detail. I resent every leaky abstraction and half-baked parser that has required me to learn such details about the spec. Android specifying the alias that they want you to prefix their namespaced attributes with; writing their documentation as if they expect you to type out your manifest by hand, instead of just providing a schema that all of the existing tooling could work with, well...
Look I don't know what's happening their side, I cant say for sure they're trwtf, but it sure seems as if they're doing something wtfy.

Gąska

@Buddy said:

Namespaces are an implementation detail.

They're not implementation detail. They're the interface.

@Buddy said:

Android specifying the alias that they want you to prefix their namespaced attributes with

Wait, is that actually a thing? They require your arbitrary alias for their namespace to be always called android? I thought I made this up for the purpose of making fun of XML...

Buddy

I might be exaggerating, but see for yourself:

<manifest> | Android Developers

The root element of the AndroidManifest.xml file. It must contain an <application> element and specify package attributes.…

The root element of the AndroidManifest.xml file. It must contain an <<discourse>application> element and specify xmlns:android and package attributes.

Zecc

@Gaska said:

I still don't see how namespaces help me to achieve more extensibility than simply ignoring tags I don't understand

You can ignore tags and attributes of namespaces you don't know, while still validating the stuff in namespaces you do know as pedantically as you want.

Plus, names for nodes can be chosen inside your own namespace without fear of colliding with a different interpretation of the same name inside other namespaces you don't control (whether this happens in practice is a different matter) The same reason for using namespaces in code, really.

@Gaska said:

It can be done in other ways too. Namespace is just one way. Extremely verbose, extremely complicated way that was declared the standard.

Like what? May very well be I lack imagination, but it feels quite elegant and terse to me.

Zecc

@Buddy said:

I might be exaggerating, but see for yourself:

<manifest> | Android Developers

The root element of the AndroidManifest.xml file. It must contain an <application> element and specify package attributes.…

The root element of the AndroidManifest.xml file. It must contain an <<discourse>application> element and specify xmlns:android and package attributes.

?

Requiring xmlns:android;
Requiring manifest root element and package attribute while not specifying a root namespace.

Buddy

@Gaska said:

@Buddy said:
Namespaces are an implementation detail.

They're not implementation detail. They're the interface.

Like I said, I'm not an xml expert. But the way I always saw it, the schema was the interface, the namespace was just how to tell the framework which schema relates to which element. The only use I've had for it was when I edited our schemas, I bumped the version number in the urn, then any code that was still producing xml with the 1_0_0 namespaces failed tests and I could update it.

Gąska

@Zecc said:

You can ignore tags and attributes of namespaces you don't know, while still validating the stuff in namespaces you do know as pedantically as you want.

Read my earlier post about what I think about overzealous validation.

@Zecc said:

Plus, names for nodes can be chosen inside your own namespace without fear of colliding with a different interpretation of the same name inside other namespaces you don't control (whether this happens in practice is a different matter)

It's not different matter - the answer to that last question determines whether your whole point is valid or not.

@Zecc said:

The same reason for using namespaces in code, really.

The difference is, it's very common to have five or six libraries in the same project, each of them having its very own Vec2f class, whereas having two different tags with two different meanings in a single XML file is very rare.

@Zecc said:

Like what?

Like what what?

Zecc

@Gaska said:

Read my earlier post about what I think about overzealous validation.

Will do when I'm more awake. I resent join this discussion now.

@Gaska said:

Like what what?

I was initially referring to "other ways" of "allow[ing] adding new element types to an existing schema (at extension points specified in the original) without breaking backward compatibility.", but on a second reading I see two key factors I missed; namely "new elements" and "existing schema".

Look, just ignore me. I shouldn't post while drowsy.

Gąska

Wait a second.

@Zecc said:

adding new element types to an existing schema (at extension points specified in the original)

@Zecc said:

at extension points specified in the original

@Zecc said:

specified in the original

Am I reading this right? Does it mean that I have to actually specify in my schema where I expect the things I cannot even predict to be, or otherwise it won't work?

Buddy

Xsd is static typing, what's the problem?

Meanwhile, json schema, which is still a draft, by the way, and each version of the draft gives no fucks about compatibility with previous versions, shits all over existing static type systems. In xsd, a choice tag lets you specify either field a of type A, or field b of type B, c instanceof D, etc. But json schema anyOf, oneOf, and allOf apply to the same object. That is, you can only specify an a, and say that it inherits from one or more types. This might seem like a small issue; there's plenty of ways to work around it, but the way I see it, the fact that there are multiple ways to solve it means that in the long run (and it will be a long run, specifically because of choices like this) means that json is gonna end up being just as painful for interop as xml already is, and the fact that they're making decisions like this suggests that json us always gonna favor duct-typed languages over real ones. So why bother.

Filed under: ...a world in which text formats are not judged by the angle of their brackets, but by the contents of their character data

Gąska

None of this answers my question: do I have to specify anything special in my XML to get the benefits of namespaces or not?

Ragnax

@Buddy said:

duct-typed

<pedant>duck-typed</pedant>

And it's no worse than late-bound methods or properties grabbed via reflection APIs which is how most ORM mapper software works in 'real languages', for instance.