Android manifest
-
Like I said, I'm not an xml expert.
Is anyone?
That's not just rhetorical. I really don't think anyone is an expert in XML anymore. It's been "organically grown" to the point no one understands it.
-
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?
No. A schema is used to define an XML grammar. Here's an example...
You wake up one morning and decide to you are going to save the state of your game to an XML file. Your program only supports 10 high scores in the UI, so you add a corresponding constraint to your schema. You coded the metadata section with the intention that people could add their data (work with me here, I can't think of a valid reason either), so you mark that part of the schema open (by adding an
<xsd:any>), and you were lazy when coding the character inventory and wrote horrible code that requires elements to be in a specific order so you are very specific in that part of the schema.When you load a game save, you validate it against your schema first. If it fails validation, you don't pass it to the load method. That's it... that's all the schema does. You don't expect it to predict the future, you don't post it to the Internet. You wrote this one schema for this one purpose and that's what it does.
Your problem with XML is you think it was sold to do everything and you seem to be constantly frustrated that it doesn't live up to your expectations. XML really doesn't do all that much, but it's mostly pretty good at what it does. Everything you have mentioned about "shortfalls" of XML are things that it was never intended to do and was never advertised to do.
-
The idea of user agent is that every browser will have distinct one.
Jaime:
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?
You are either trolling or clueless. I choose to believe that you are clueless.
-
I still don't see how namespaces help me to achieve more extensibility than simply ignoring tags I don't understand.
XML never promised that your code would magically acquire new features. All that it accomplishes is to be a format that allows old code to read extended documents without the new extension data making old programs barf. That's it... nothing more.
-
No. A schema is used to define an XML grammar.
To what extent?Here's an example...
You wake up one morning
Fuck you and your bedtime stories. Get to the point.You coded the metadata section with the intention that people could add their data
This sentence proves that the answer to my question is indeed "yes", not "no". If I even need to as much as think for a second about extensibility for my XML format to be extensible, namespaces instantly become 12 times less attractive option. At which point it's just barely better than any other solution to this same problem.
-
You are either trolling or clueless. I choose to believe that you are clueless.
I am clueless. That's why I asked. If the convention isn't an official recommendation or part of definition of well-formed document, it's ten times less effective than it could be and there is a very high risk that someone might do it another way, which you can't blame them for because they didn't break any standard.XML never promised that your code would magically acquire new features.
The whole topic (and that other one too) was you and several other people trying to convince me that using namespaces magically makes my format extensible.
-
This sentence proves that the answer to my question is indeed "yes", not "no"
Actually, the answer to your question is “In XSD, yes”.
Please, keep in mind, that XSD is not part of the XML specification. It is additional tool on top of it.
overzealous validation.
History has proven several times already that being indiscriminately liberal in what you accept is not the best course of action, because then some will generate crap that will get in the way of future extensions.
However, XSD is overzealous in most places. Or rather, XSD defaults to overzealous and requires careful use and additional verbiage to use it reasonably (i.e. allow different order and allow elements from different namespaces anywhere).
Also, most programs don't validate with XSD anyway (and there is not much point in it) as part of the normal loading. The XSD is more of a testable documentation. So if the XSD does not specify that extensions must be present, most programs will accept (and ignore) them anyway. Which is right; not doing so is overzealous validation).
The whole topic (and that other one too) was you and several other people trying to convince me that using namespaces magically makes my format extensible.
Not really magically. They provide an obvious way to make it extensible, so you don't have to think about all the details you'd need to solve for most other formats.
And XSD gets in the way of that a bit and yes, it is not good. Fortunately, few actually use it that way.
-
<pedant>duck-typed</pedant>
http://epicwomen.org/wp-content/uploads/2012/07/Duck_Tape.jpg
Close enough.
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.
Well, it's worse right now, because there aren't even any tools that can map such schemas into objects. And if the long-term plan is just to provide something ‘no worse’ than what we already have, why bother?
-
Close enough.
Nice try, but no. Duck-typing has nothing to do with duck tape.
Duck-typing identifies an object's fitness-for-purpose by examining its shape, i.e. , looking which methods, properties, etc. it has available. The origin of the term comes from the aptly named duck test: "If it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck."
-
At which point it's just barely better than any other solution to this same problem.
Yes, better. What's wrong with being a little bit better?
-
Actually, the answer to your question is “In XSD, yes”.
Please, keep in mind, that XSD is not part of the XML specification. It is additional tool on top of it.
So if I understand correctly, I can only achieve automatic extensibility only if I completely ditch XSD?History has proven several times already that being indiscriminately liberal in what you accept is not the best course of action, because then some will generate crap that will get in the way of future extensions.
So I want my format to be extensible, but only if there are actual extensions already? Wouldn't that be backwards-incompatible?Not really magically.
Magically in the sense I don't have to explicitly specify and code around it. That's the impression I've got for most of the discussion, and only in the latest several posts someone told me that it was a lie and that XML namespaces provide extensibility only if I prepared my XSD right and only in places specified in my XSD, unless I completely ditch the XSD and do whatever. The problem is, the former isn't any better than just ignoring<ext>tag and its content (actually, it pretty much means exactly this), and namespaces doesn't change anything in this regard, and the latter is the solution I proposed all the way through, but the downside is that any XSD would be a lie (I don't particularly care about it, but seems like you do about XSD being correct).They provide an obvious way to make it extensible, so you don't have to think about all the details you'd need to solve for most other formats.
The most obvious solution for JSON is to haveextobjects that can be in arbitrary form. For XML with XSD and namespaces, it turns out the solution is identical.And XSD gets in the way of that a bit and yes, it is not good. Fortunately, few actually use it that way.
So if almost whole industry decided to not use XSD for what they were designed for (namely, validation), it's all a lie after all.
-
Yes, better. What's wrong with being a little bit better?
Note that I wrote this 7 posts ago, before I learned some new important facts. Now it qualifies as slightly worse than alternatives.
-
So if I understand correctly, I can only achieve automatic extensibility only if I completely ditch XSD?
You do not understand correctly.
"Automatic extensibility" is impossible. Your code cannot figure out how to properly handle things that were invented after your code was written.
However, real-world extensibility system do exist. They're usually called plug-ins or add-ins. The plug-in provides the actual functionality, but the core program needs to have some way to know what plug-ins to load and the plug-ins often need to consume data.
It is entirely up to you to code a functional plug-in system. XML will do nothing to provide extensibility. Part of your job will be to define how your data could be extended. If you use an XSD, it is your responsibility to modify it in such a way that a document with extended data validates.
The one thing that XML provides that few other formats do is a native implementation of third party data conflict avoidance. This is done via namespaces. For example, if to plug-ins add date metadata, it's conceivable that they might use the same name as each other and create a conflict. Using namespaces properly makes this impossible.
Let me repeat - XML doesn't do much. Every "weakness" you have identified comes from the fact that you expect too much from it. Lower your expectations. Even better, follow this general rule: If you are expecting XML to do something that is impossible (like handle extensibility all by itself), it is your understanding that is in error.
Please stop posting criticisms that follow the pattern of "XML sucks because it didn't do the impossible".
-
"Automatic extensibility" is impossible.
It's certainly possible. If I ignore tags I don't recognize, I gain all the extensibility I want - I can add any tags anywhere I want without ever breaking backwards compatibility - without writing a single line of code specific to extensibility.Your code cannot figure out how to properly handle things that were invented after your code was written.
The point is not to properly handle it, but to not shit your pants because the file isn't 100% understandable to you.However, real-world extensibility system do exist. They're usually called plug-ins or add-ins. The plug-in provides the actual functionality, but the core program needs to have some way to know what plug-ins to load and the plug-ins often need to consume data.
Program functionality extensibility is a different beast than data format extensibility.The one thing that XML provides that few other formats do is a native implementation of third party data conflict avoidance.
Which is almost never a problem. But I must admit, if you want to have 99.999% certainty that no conflict will arise, then absurdly long prefixes and #defines is a pretty decent solution.For example, if to plug-ins add date metadata, it's conceivable that they might use the same name as each other and create a conflict. Using namespaces properly makes this impossible.
Unless they use the same namespace. The absurd length of namespaces makes it extremely unlikely, but still.Let me repeat - XML doesn't do much. Every "weakness" you have identified comes from the fact that you expect too much from it.
I expect it to not get in my way. Is it too much?Lower your expectations.
To the level I have for garbage collector to not hurt the performance of my game too much?Please stop posting criticisms that follow the pattern of "XML sucks because it didn't do the impossible".
Please stop calling impossible something that I provided general draft of implementation for.
-
It's certainly possible. If I ignore tags I don't recognize, I gain all the extensibility I want - I can add any tags anywhere I want without ever breaking backwards compatibility
XML does this by default. So, I don't understand what you are looking for.
The point is not to properly handle it, but to not shit your pants because the file isn't 100% understandable to you.
Yup, already happens.Unless they use the same namespace. The absurd length of namespaces makes it extremely unlikely, but still.
The only way for two extensions to use the same namespace is for one of them to incorrectly claim they control an Internet URL. The existing namespace convention already covers this, making it 100% impossible to have a conflict unless someone makes a grievous error.I expect it to not get in my way. Is it too much?
I doesn't.Please stop calling impossible something that I provided general draft of implementation for.
You just provided a general draft of implementation for something that XML already does just fine. I was under the impression you were asking for something that is either an edge case you weren't aware of, or something that XML doesn't do. Also, you used the word "automatic", I don't see how ignoring added data counts under any definition of "automatic extensibility".
-
XML does this by default. So, I don't understand what you are looking for.
If XML does this by default, then I'm looking for a reason to have namespaces. Or XSDs at all. Because from what I've got from that other topic, there's some bound between a namespace and an XSD, even if it's purely conceptual.Yup, already happens.
Not "already happens" but happens if I throw away validation against XSD, or make XSD extensions-aware.The only way for two extensions to use the same namespace is for one of them to incorrectly claim they control an Internet URL.
Yes. Exactly. It can happen due to domain expiring and being registered by someone else - an example of non-purposeful conflict. Or it can happen if the URN isn't URL, which is a valid namespace too, isn't it?I doesn't.
Yes it does. XSD at least. And XSD is as much a part of XML as CSS is part of HTML.You just provided a general draft of implementation for something that XML already does just fine.
Makes it even funnier for you to call it impossible.Also, you used the word "automatic", I don't see how ignoring added data counts under any definition of "automatic extensibility".
We are talking about format extensibility, not functionality extensibility. These are two very different things without any implied relation with one another. Format extensibility means that I can make a new version of format and the files valid according to the new version of format will be also valid according to the old version. The fact that the old program can't make sense of the new data is irrelevant - it should be enough for the old implementation to deal with what it's already dealing with.
-
If XML does this by default, then I'm looking for a reason to have namespaces. Or XSDs at all. Because from what I've got from that other topic, there's some bound between a namespace and an XSD, even if it's purely conceptual.
Namespaces are there for collision avoidance. Nothing more. XSDs are a tool that you can use when it makes your life better. If you feel schemas makes your life worse, feel free to not use them.
Not "already happens" but happens if I throw away validation against XSD, or make XSD extensions-aware.
XSD has the concept already built in. The xs:any element means "allow any element here" and the xs:anyAttribute element means "allow any attribute here".Yes. Exactly. It can happen due to domain expiring and being registered by someone else - an example of non-purposeful conflict. Or it can happen if the URN isn't URL, which is a valid namespace too, isn't it?
Read this.We are talking about format extensibility, not functionality extensibility.
Then there is no "automatic" and XML handles everything well already. What are you complaining about?
-
XSD has the concept already built in.
Bullshit.The xs:any element means "allow any element here" and the xs:anyAttribute element means "allow any attribute here".
And both have to be written somewhere in XSD, and they only allow arbitrary data where they were designed to. That's quite different from what I was talking about.Read this.
It boils down to "don't use URLs for XML namespaces". Which is contrary to what everyone does. And what you personally recommended.Then there is no "automatic" and XML handles everything well already. What are you complaining about?
I'm complaining about namespaces being totally orthogonal concept to extensibility, despite what you (and guys from the other topic) said to me. I mean, you're
a lot here, so it might be not what you're saying now, but you definitely was saying it earlier.
Also, I'm complaining about XSDs killing extensibility unless the developer had enough forethought to prevent this.
-
It boils down to "don't use URLs for XML namespaces". Which is contrary to what everyone does. And what you personally recommended.
Poor reading comprehension.
@From the Linked Article said:
Whether it's better to use URLs or URNs is the source of some debate. ... Use URLs for namespaces if you are careful to place some sort of document at the URL that would be useful for a reader. ... use URNs if your organization has a means of managing and resolving a suitable class of URN.
And both have to be written somewhere in XSD, and they only allow arbitrary data where they were designed to. That's quite different from what I was talking about.
No they don't. Most software doesn't run a document through the XSD on use. Some software does... when it provides some meaningful benefit to that software, but it's not very common.
I'm complaining about namespaces being totally orthogonal concept to extensibility
That's the freaking reason namespaces were invented.Also, I'm complaining about XSDs killing extensibility unless the developer had enough forethought to prevent this.
Nope. In most real-life cases, an XSD is something that is created by a vendor and used by a developer. If used this way, all it describes is the parts of the document that are under the control of that vendor.Just for shits and giggles, I just pulled a report from our SQL Server Reporting Server, which uses an XML based report definition. I added a namespace and a custom attribute to it and uploaded the change to the server. As expected, SSRS simply ignored my custom namespaced additions.
-
Poor reading comprehension.
Use URLs for namespaces if you are careful to place some sort of document at the URL that would be useful for a reader.
Note that it says "use URL if...", not "... if you use URL".
use URNs if your organization has a means of managing and resolving a suitable class of URN.
I can barely understand what they mean by it. Especially since the namespace URN will be never tried to be resolved with anything.
Most software doesn't run a document through the XSD on use.
What is XSD for, then, if not for use?Some software does... when it provides some meaningful benefit to that software, but it's not very common.
The class-generation-from-XSD thing that someone was talking about in the other topic pretty much implies validation against XSD. Are you saying that it's not, or that these generators are very rarely used in practice?Nope. In most real-life cases, an XSD is something that is created by a vendor and used by a developer. If used this way, all it describes is the parts of the document that are under the control of that vendor.
Like a documentation! Man, I wish my vendor provided me some documentation that's in actually human-readable format...Just for shits and giggles, I just pulled a report from our SQL Server Reporting Server, which uses an XML based report definition. I added a namespace and a custom attribute to it and uploaded the change to the server. As expected, SSRS simply ignored my custom namespaced additions.
Is it bad? Because everybody kept telling me that my idea of just ignoring stuff I don't care about is
.
-
Is it bad? Because everybody kept telling me that my idea of just ignoring stuff I don't care about is
.that's what i do in out JSON data objects for our REST services. I'll deserialize with JSON.NET, do validation and then run the thing.
i don't much care if you give me extra keys, or omit optional keys. just so long as i have the data i need to do what you asked me to do.
-
Because everybody kept telling me that my idea of just ignoring stuff I don't care about is
.No, we are telling you that writing your own XML parser so that you can ignore things you don't care about is
because you can just as easily ignore things you don't care about without introducing the 
of your own parser.
-
No, I was specifically told that using a generic proper XML parser everyone uses and make it ignore unknown tags is
.
-
-
Missed that @Ragnax's post for some reason, and I have perfect reply!
Duck typing means that any object can be used anywhere if you spend some effort to make it fit its designated place. A duct tape is a perfect tool for that. Doesn't hold up? Duct tape! Too loose to sit in a hole? Duct tape! Cables are a mess and you care about aesthetics? Duct tape! You and your girlfriend have sudden urge for BDSM? Duct tape!
-
Sounds like duck type? Duck tape!
-
Duck typing means that any object can be used anywhere if you spend some effort to make it fit its designated place. A duct tape is a perfect tool for that. Doesn't hold up? Duct tape! Too loose to sit in a hole? Duct tape! Cables are a mess and you care about aesthetics? Duct tape! You and your girlfriend have sudden urge for BDSM? Duct tape!
Still doesn't change the fact that duck or duct tape is in no way connected to the origin of the term duck typing.
But whatever; have your moment.
-
My post quacks like an explanation how they're related. Isn't that enough?
-
You done missed a joke.
-
And even if he didn't, it looks like he did
-
No, I was specifically told that using a generic proper XML parser everyone uses and make it ignore unknown tags is
.XML parsers load the entire contents of a document into a node tree. The parser does nothing with that tree except handed it to your program. Why would it be necessary to ignore tags in the parser when they can just as easily be ignored by your code?
Given that information, your statement rewords to this:
No, I was specifically told that using a generic proper XML parser everyone uses and using it the way everyone else does is
.
Obviously the problem is how you came to think someone said this to you (or why you believed them when they did). I'm constantly surprised at how readily you believe obvious crap, and then cling to the horrible misstatement like it's a life jacket. It's almost like you want XML to suck and you're looking for a good justification.
-
XML parsers load the entire contents of a document into a node tree.
I'm no XML expert, but my understanding is that SAX parsers do not build the whole tree, but give it to you a piece at a time through callbacks. Still, it's up to your code what to do with each piece — process it or ignore it; the parser doesn't make those decisions.
-
SAX is another animal, but it's not used that often. Even is the case of SAX, by default the parser sends every event to your app, but if you have no code, it does nothing other than read the file and freak out if it is not well-formed. So, it is still not necessary to have the parser ignore anything.
-
So, it is still not necessary to have the parser ignore anything.
Yep, that's what I said. It's nice to get agreement, though, from somebody who seems to know more about it than I do.
it's not used that often.
Yeah, your code is a lot more complicated. Unless your XML is huge, the complexity outweighs the benefits.I haven't had to do much XML parsing, and the first time I did, naturally, I Googled how to do it. SAX and DOM. Well, not having the whole tree eat up memory seems like a good idea, so I think I'll go with SAX. Read some more; start implementing. Ooookkay, my XML file is small; having the whole tree in memory isn't really an issue.
DOMParserit is.
-
XML parsers load the entire contents of a document into a node tree. The parser does nothing with that tree except handed it to your program. Why would it be necessary to ignore tags in the parser when they can just as easily be ignored by your code?
Define parser. In particular, define the line between parser and... whatever continues to parse input after parser.
-
Look... I told you it was idiotic to write your own parser when there are hundreds in existence. Obviously, I meant whatever definition of parser that makes "hundreds in existence" actually makes sense. If you had another definition in mind, that conversation should have made zero sense and you should have raised the issue at the time. I'm not going down a pedantry rabbit hole and I'm not indulging any of this goalpost moving.
-
Look... I told you it was idiotic to write your own parser when there are hundreds in existence.
Parser is a broad term. What specific kind of parser do you mean? Because generic XML parser, XSD parser, XAML parser, and SOAP parser are all XML parsers, but they do different things.Obviously, I meant whatever definition of parser that makes "hundreds in existence" actually makes sense.
The "internal tool used by only one company that handles the file like nothing else can handle because nobody tried, because nobody needed to deal with this company's internal file formats" makes sense to me, and there are hundreds of these in existence. Is this what you meant?If you had another definition in mind, that conversation should have made zero sense and you should have raised the issue at the time.
By XML parser, I meant one that parses my XML file, from the very beginning all the way through to final results. But you seem to only care about the part of parser that deals with transforming text into tree form. With the latter, the entirety of both the topics are irrelevant because this kind of parser is too low-level for the concept of namespaces to be any relevant. Neither does the concept of invalid tag.
-
I can barely understand what they mean by it. Especially since the namespace URN will be never tried to be resolved with anything.
Given that the linked article was written in 2004, and that the author is explicitly recommending that the URI used as the namespace point to actual documentation, it's a small leap to conclude that this author's recommendation is -sadly- at odds with current thinking in regards to where one stores one's XML schema documentation.
I happen to know (because I wasted my youth on this shit) that the habit of poorly-written -often hand-rolled- XML parsers to load, (without caching) the resource at the namespace URI -often on every XML document load- lead folks to choose to stop putting files at the namespace URI.
-
So if I understand correctly, I can only achieve automatic extensibility only if I completely ditch XSD?
More or less, yes. XSD is not very friendly to extensibility. XSD is not very friendly to many things.
latter is the solution I proposed all the way through, but the downside is that any XSD would be a lie
Not exactly, but mostly yes. It is possible to write the XSD not to be a lie in that case, but few bother.
I don't particularly care about it, but seems like you do about XSD being correct
I don't give a damn about XSD even existing, not to mention being correct in any sense! I've only ever used XSD as a formalized documentation. Because writing “correct” XSD is pain in the arse and it is not very useful anyway, because XSD is too strict for some things and can't specify other more useful constraints anyway.
So if almost whole industry decided to not use XSD for what they were designed for (namely, validation), it's all a lie after all.
XSD is not part of XML. It was created later to replace DTDs.
The most obvious solution for JSON is to have
extobjects that can be in arbitrary form. For XML with XSD and namespaces, it turns out the solution is identical.extobjects are not very good, because it is still just one identifier. What you need is prefixed identifier. And then it is equivalent. After all, that's exactly what HTML and CSS do (see all the-webkit-something and-firefox-something etc. properties).Also the cases where this kind of extensibility is most useful actually all turn out to be where XML is used really as markup and not as data serialization format. JSON is only a data serialization format and you rarely need that extensible and even less often need to mix attributes from different specifications in one. As serialization format, XML does not have much advantage, and the advantage of it being eFfing verbose is totally real.
Read this.
More of a reason why XSD is not a good tool for validating anything.
It can still be used for documenting, with the advantage that it can be used in unit test for checking that the documents produced actually match the documentation. And that still provides some advantage to XML over formats with no schema (yes, I know there is some kind of schema for JSON now).
-
XSD is not part of XML.
And CSS is not part of HTML.ext objects are not very good, because it is still just one identifier.
Did you know that XML allows nested tags? And that JSON allows nested objects? Besides, I was talking about the most obvious, not the best. The best is ignore all superfluous tags but allow access to them in plugin API, but that requires somewhat more code in the application so the extensions would be properly bound to the known objects.What you need is prefixed identifier. And then it is equivalent.
I said, equivalent to XML with XSD, not just XML with namespaces.JSON is only a data serialization format and you rarely need that extensible
Well, truth to be told, extensible file formats are rarely needed in general. We're talking about cases where we already established that they are needed. And I can think of several use cases where such unlimited extensibility is useful (say, you make an IDE, and want your plugins to be able to store any additional data they need in your project file).even less often need to mix attributes from different specifications in one
I'd be pretty confident to claim that you never need it. At all. But I might be wrong because I might be ignorant of some very crazy niche.
-
And CSS is not part of HTML.
XSD is not part of XML in a sense in which CSS is, integral, part of HTML. HTML 4 and newer needs CSS. XML does not need XSD for anything.
-
You can write HTML4/HTML5 just fine without a single line of CSS. It won't be good looking, but ultimately nothing you write in HTML depends on anything you write in CSS, and vice versa.
-
You can write HTML4/HTML5 just fine without a single line of CSS.
That is not true. You can write HTML4/HTML5 without writing a single line of CSS yourself, but it will still use CSS, because the rendering rules are specified in terms of CSS (the browser still must e.g. apply user stylesheet). Nothing about XML is specified in terms of XSD.
-
This post is deleted!
-
That is not true. You can write HTML4/HTML5 without writing a single line of CSS yourself, but it will still use CSS, because the rendering rules are specified in terms of CSS (the browser still must e.g. apply user stylesheet).
What if I read HTML without rendering? Say, in a web crawler? Do I still need CSS for anything? Is this invalid use of HTML?
-
What if I read HTML without rendering? Say, in a web crawler? Do I still need CSS for anything? Is this invalid use of HTML?
That only shows that CSS is not needed for everything with HTML. But it still needed for some things, and that includes the most important things.
But you don't need XSD for anything. It is purely a tool on top of XML that is completely optional.
-
duck or duct tape is in no way connected to the origin of the term duck typing.
Exactly. Still doesn't explain why you brought up duck typing when someone mentioned duct tape...
-
That only shows that CSS is not needed for everything with HTML. But it still needed for some things, and that includes the most important things.
Don't confuse writing HTML with making website.
-
By XML parser, I meant one that parses my XML file, from the very beginning all the way through to final results.
But now you're talking about your code - which is a goalpost shift from any discussion that could possibly have a valid answer of "use a library". So, your definition of XML parser is not suited for a reasonable discussion of roll-your-own-ness.
-
Also, I'm complaining about XSDs killing extensibility unless the developer had enough forethought to prevent this.
So, you are complaining that a formal definition of what a document can contain kills extensibility unless the person doing the defining explicitly includes a provision for extensibility. That's insane.
