Android manifest



  • @ixvedeusi said:

    Exactly. Still doesn't explain why you brought up duck typing when someone mentioned duct tape...

    Because someone brought up the term duct-typing without knowing what they were typing about.


  • Banned

    @Jaime said:

    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".

    If I wanted to write a .docx editor, should I roll my own OOXML reader based on generic XML parser, or rather use a library?

    It's not goalpost shift - it's specifying what we forgot to specify 100 posts ago.

    @Jaime said:

    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.

    Look:

    • in that other topic, I asked what XML is good for
    • I've got an answer that namespaces are cool
    • I asked what is the benefit of namespaces over just using prefixes
    • I've got an answer that since each individual namespace is separate XSD, I can validate different parts of my XML file with different XSDs; without namespaces, I would have to include everything in a single one
    • I argued that this is a solution to a problem that was made by having XSDs in the first place
    • They argued that the alternative is no validation at all, which is wrong

    Then it got a little crazy, then it was carried over to this topic, and at the end I learn that nobody uses XSDs, namespaces are literally the same as prefixes, and XML provides no benefits whatsoever except for shorthand notation of ridiculously-long-by-design prefixes. OF COURSE I'M GONNA COMPLAIN ABOUT EVERYONE AROUND LYING TO ME.



  • @Gaska said:

    I've got an answer that since each individual namespace is separate XSD, I can validate different parts of my XML file with different XSDs; without namespaces, I would have to include everything in a single one

    This is where things went wrong. A namespaces and XSDs have nothing to do with each other. It's perfectly fine for an XSD to specify that a document can have attribute from any number of namespaces, or even for the XSD to specify that nothing should have a namespace.

    If you simply disregard this statement as nonsense, you should get a better picture of reality.

    @Gaska said:

    I argued that this is a solution to a problem that was made by having XSDs in the first place

    No, it's not. The issues that prompted namespaces (and the introduction of namespaces as a solution) existed in the late 1990's and XSDs weren't introduced until 2001.

    @Gaska said:

    They argued that the alternative is no validation at all, which is wrong

    No one said you shouldn't validate, just that it's an entirely different discussion. In reality, there's not much difference between code that errors due to a validation issue and code that errors due to a missing required tag in an XML document. You'll probably find it easier to create good error messages for the latter scenario.

    @Gaska said:

    COURSE I'M GONNA COMPLAIN ABOUT EVERYONE AROUND LYING TO ME.

    The problem is you called all the corrections lies and refused to realize the lies were only a few statements made to you much earlier.



  • @Gaska said:

    I asked what is the benefit of namespaces over just using prefixes

    :wtf: do you mean "just using prefixes"? When you use a prefix in XML, you're supposed to define what namespace it represents. If you don't, a good XML parser should at least throw a warning in your face. My understanding is that an undefined prefix defaults to whatever default namespace your parser uses (something like http://www.tempuri.org), then having two undefined prefixes would be just as effective as having no prefixes. There really is no effective difference between:

    <root>
        <something/>
        <somethingelse/>
    </root>
    

    and:

    <root>
        <a:something/>
        <b:somethingelse/>
    </root>
    

    In both cases, all elements would end up in the default namespace. Since one of the primary benefits of namespaces is to avoid name conflicts, using a prefix without defining the namespace is less than worthless. This is true whether you are using XSDs or not.

    @Gaska said:

    end I learn that nobody uses XSDs

    I use XSDs all the time. I utilize XSDs from some third party partners that define the XML structures of uploads we are to send them or downloads we are to receive from them. I send XSDs to others who we communicate with using XML over secure channels. I maintain several RESTful web services which also have SOAP endpoints, and I provide WSDLs including schema definitions which could be extracted as complete XSDs. Just from the companies I interact with, I can name a couple dozen which use XSDs. One of those is an international tech company that makes billions per year, and there's a very good chance that you use their products.

    @Gaska said:

    XML provides no benefits whatsoever except for shorthand notation of ridiculously-long-by-design prefixes.

    Uh-huh. It's not like it's a good format for serializing objects, or sharing data in a standardized format that's been working for years. Are there other ways that may be better suited to your needs? Maybe. But XML works well for what it does, just don't try to shoehorn it into every possible situation.

    @Gaska said:

    OF COURSE I'M GONNA COMPLAIN ABOUT EVERYONE AROUND LYING TO ME.

    That was a meager attempt at a blakeyrant. I give you a 3/10. Next time, try spreading the caps and name calling throughout your post instead of concentrating it like that with the bold-italics. It's more effective when you spread it out.


  • Grade A Premium Asshole

    @Gaska said:

    ...at the end I learn that nobody uses XSDs...

    I make use of XSDs for two things:

    1. Define and automatically populate an Erlang record with a well-formed XML document.

    2. Have my XML parser scream (and abort the parse) when upstream makes a significant, unannounced change to the structure of the XML that they are sending to me. In my software, a change to the form of the XML document likely means a significant change to the meaning of the document, requiring inspection of the new document and code changes to add new logic.

    There are people who use XML as a data serialization format and need rigidly defined formats. You enforce those formats by writing XSDs that are inflexible and validating the XML against that XSD. (It's entirely possible to write flexible XSDs, but it is more work.)


  • Banned

    @Jaime said:

    This is where things went wrong.

    I wonder why?

    @Jaime said:

    If you simply disregard this statement as nonsense, you should get a better picture of reality.

    Someone should have told me this two days earlier!

    @Jaime said:

    No, it's not. The issues that prompted namespaces (and the introduction of namespaces as a solution) existed in the late 1990's and XSDs weren't introduced until 2001.

    The issue of not being able to put more into a file than XSD allows? Yep, totally an issue that existed before XSD was invented.

    @Jaime said:

    No one said you shouldn't validate

    They didn't. They said the polar opposite of this - that I SHOULD validate if my format doesn't have anything more than it should. They even gave me an example of error it helps to prevent!

    @Jaime said:

    In reality, there's not much difference between code that errors due to a validation issue and code that errors due to a missing required tag in an XML document.

    What about code that errors due to a validation issue and code that doesn't error at all because the "invalid" file still has all the required data?

    @Jaime said:

    The problem is you called all the corrections lies

    Yes, after they've been corrected. If a correction of a correction of a correction of a correction is made, it means that the correction of the correction of the correction was a lie.

    @Jaime said:

    refused to realize the lies were only a few statements made to you much earlier

    Which ones do you have in mind exactly?

    @abarker said:

    :wtf: do you mean "just using prefixes"?

    I mean having tags like <android-something>, not just plain <something>. And then filter these prefixes by hand, using some library.

    @abarker said:

    When you use a prefix in XML, you're supposed to define what namespace it represents.

    Oh, sorry. I forgot a prefix has a very specific meaning in XML that's different from the normal meaning of a prefix.

    @abarker said:

    I use XSDs all the time. I utilize XSDs from some third party partners that define the XML structures of uploads we are to send them or downloads we are to receive from them. I send XSDs to others who we communicate with using XML over secure channels. I maintain several RESTful web services which also have SOAP endpoints, and I provide WSDLs including schema definitions which could be extracted as complete XSDs. Just from the companies I interact with, I can name a couple dozen which use XSDs. One of those is an international tech company that makes billions per year, and there's a very good chance that you use their products.

    Then @Jaime lied to me! Again!

    @abarker said:

    Uh-huh. It's not like it's a good format for serializing objects

    It's not. Besides, you haven't realized that I was talking about benefits w.r.t. extensibility. You could easily infer it from the context if you spent a quarter second more to not just read, but also understand my post.

    @abarker said:

    or sharing data in a standardized format that's been working for years

    XML doesn't define format of data. It defines format of format of data. And these XML formats are usually made up on the spot and only ever used in one place each.



  • @Gaska said:

    I mean having tags like <android-something>, not just plain <something>. And then filter these prefixes by hand, using some library.

    That's a "pretty good" solution that will work. However, XML's namespace solution has every benefit your solution does (except terseness), while adding a guarantee that no two authors could have a name collision. That makes the standard XML way of doing it by namespace an "excellent solution". Why would you roll your own solution that's not quite as good as an industry accepted solution and call it an improvement?

    @Gaska said:

    Then @Jaime lied to me! Again!

    No, I said few people validate against an XSD while loading documents for use. @abarker provided several other uses for XSD just to show that they are, in fact, useful. Notice that his list is a bunch of cases of using XSD to communicate schema to developers or for use in development tools, the most common categories of XSD use.


Log in to reply