Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 23

Thread: Xsd.exe errors?

  1. #11
    Junior Member
    Join Date
    Dec 2006
    Posts
    3

    I reported this bug to MS.

    I reported this bug to MS via "MS Connect" site.
    Anybody can send bug report via the site ealsily.
    I was suprised about nobody sent bug report until now.

    Oh one man sent the report, but he did not include schema file, so MS couldn't reproduce the bug, and it has been ignored.

    My report is listed in:
    https://connect.microsoft.com/VisualStu ... kID=289668
    (You need MS passport account)




    I have no support request right, so I cannot request support for this problem. If you have support right, you may make MS to make a hotfix for this bug. Via MS support site.

  2. #12
    Gero
    Guest

    Topic closed :(

    Hi,

    the topic was closed unresolved by MS.

    http://connect.microsoft.com/VisualStud ... kID=289668

    They say they can workaround it, but I don't have any clue how to do this myself.

    Maybe someone can upload a *.xds file without these OpenGL things,
    so we have a starting point after all.
    I'll try, but expect too much

    Greetings

    Edit: All commercial databinder/xml2code/class designer failed to create proper code, since they all use the MS XML tool and code provider.
    Maybe some more names instead of references work better?

  3. #13
    Senior Member
    Join Date
    Jan 2006
    Location
    Foster City, CA
    Posts
    540
    The generated code isn't worth all that much IMO. If I were redesigning the Collada DOM from scratch I wouldn't even include the generated classes. You would just work with the raw string data, and there'd be helper functions to do things like convert an array of float strings to an array of floats, etc. I'm pretty sure that when Remi did Collada for XNA he just used .Net's native XML support, without any generated classes. It didn't prevent him from getting stuff done.

    Anyway that's just my take on it. Sorry to hear that Microsoft won't fix the bug. At least they acknowledged it I guess.

  4. #14
    Junior Member
    Join Date
    Sep 2008
    Posts
    5
    Quote Originally Posted by sthomas
    The generated code isn't worth all that much IMO. If I were redesigning the Collada DOM from scratch I wouldn't even include the generated classes.
    The generated classes save you all the trouble of writing code to parse XML in order to get something in memory and the trouble of writing code to emit the XML to get something out of memory. I've looked at doing this by hand and its a ton of work compared to using the automatically generated classes.

    The bug report on connect says that the problem can be worked around by eliminating the use the the <group> directives in the schema. I will look at doing this by XSLT. The advantage of generating classes for XML I/O directly from the schema is that it removes one more opportunity for getting things wrong.

    I'm pretty sure that when Remi did Collada for XNA he just used .Net's native XML support, without any generated classes. It didn't prevent him from getting stuff done.
    Yes, I've looked at that code as well. It doesn't leverage any of the builtin support for serializing structures in and out of XML in the .NET framework, so it too does many things manually that you can do automatically by getting xsd.exe to consume the Collada schema.

  5. #15
    Senior Member
    Join Date
    Jan 2006
    Location
    Foster City, CA
    Posts
    540
    Quote Originally Posted by legalize
    The generated classes save you all the trouble of writing code to parse XML in order to get something in memory and the trouble of writing code to emit the XML to get something out of memory.
    That's not correct. It's the xml parser that saves you from having to deal with xml streaming and formatting directly, not the code generator. Suppose I have this content:
    Code :
    <element>
        <child>
            1 2 3 4
        </child>
    </element>
    An xml parser will provide me with an API so I can analyze the structure of this content without having to do any xml parsing myself. This is extremely valuable and there are many C/C++ libraries that provide this functionality (libxml, xerces, tinyxml), but it has nothing to do with code generation.

    With a normal xml parser the content of the <child> element would be reported as the string "1 2 3 4", and then it's the client's responsibility to deserialize that into data types native to the language. This is what code generation can help you with. Although it sounds good in theory, in my experience the benefits are outweighed by the sheer enormity of the generated code, which aside from making the API larger also drastically increases the size of your binaries and makes compilation take much longer.

    I've looked at doing this by hand and its a ton of work compared to using the automatically generated classes.
    It's important to keep in mind that we're only talking about deserializing strings into native types, not parsing xml. IMO deserialization is trivial to implement, and with the right set of helper functions it isn't too much of a burden on client code either (though I'll certainly admit that it's a burden).

    I spent a lot of time working with the DOM, client code, and the DOM's code generator. I also spent some time using the more conventional xml parser interface provided by C libraries like libxml, and built-in to languages like Python with its minidom API. I vastly prefer the latter.

    Steve

  6. #16
    Junior Member
    Join Date
    Sep 2008
    Posts
    5
    Quote Originally Posted by sthomas
    Quote Originally Posted by legalize
    The generated classes save you all the trouble of writing code to parse XML in order to get something in memory and the trouble of writing code to emit the XML to get something out of memory.
    That's not correct. It's the xml parser that saves you from having to deal with xml streaming and formatting directly, not the code generator.
    Are you familiar with how Xml serialization works in .NET? Because based on the above, it seems that you aren't.

    Xsd generates classes with appropriate Xml serialization attributes on them. You then can deserialize an Xml document into the generated classes with a few lines of code. Similarly, you can serialize the data in the classes in memory into an Xml document with a few lines of code. I don't even need to call a parser directly, much less write one. The serialization classes in the .NET framework handle all of this for me.

    Suppose I have this content:
    Code :
    <element>
        <child>
            1 2 3 4
        </child>
    </element>
    An xml parser will provide me with an API so I can analyze the structure of this content without having to do any xml parsing myself. This is extremely valuable and there are many C/C++ libraries that provide this functionality (libxml, xerces, tinyxml), but it has nothing to do with code generation.
    I never said that Xml parsers weren't valuable. They are and .NET provides classes that do the Xml parsing if you want to do it yourself, but that is doing things the hard way in .NET since Xml serialization/deserialization is available by simply putting the right attributes on your data structures. Xsd.exe generates classes with the appropriate attributes to be able to serialize and deserialize documents matching the supplied schema directly from and into memory.

    I spent a lot of time working with the DOM, client code, and the DOM's code generator. I also spent some time using the more conventional xml parser interface provided by C libraries like libxml, and built-in to languages like Python with its minidom API. I vastly prefer the latter.
    ...however, all of that is from C/C++ and not .NET, so its not really relevant to this discussion because we are talking about .NET, xsd.exe's ability to generate Xml serializable classes from a schema and the Xml serialization framework built into .NET. Xml serialization goes way beyond just getting the string "1 2 3 4" from your example; if your schema said that the <child> element contains a list of integers, then Xml serialization would turn this into an array of ints and not just give you a string.

  7. #17
    Senior Member
    Join Date
    Jan 2006
    Location
    Foster City, CA
    Posts
    540
    Quote Originally Posted by legalize
    Are you familiar with how Xml serialization works in .NET? Because based on the above, it seems that you aren't.
    Lol, ok.

    xsd.exe does the same thing that the Collada DOM's code generator does: creates a set of classes that act as an xml data binding. You were saying this generated code saves you from having to deal with xml parsing yourself. My point was that even if you aren't using a code generator (e.g. if you don't have a schema), you don't have to do any xml parsing yourself. Instead you use an xml parser for that, whether you're in C or C#. In that case what you have to do manually is string serialization, not xml parsing. I have to convert "1 2 3 4" into an array of integers, but I don't have to parse the xml markup manually at all.

    Ok, hopefully we agree about that. Now the question is if the extra convenience provided by the code generator (it'll automatically convert "1 2 3 4" into an array of ints) is worth the hassle of dealing with the code generator (and it's bugs, like the one you're trying to work around in xsd.exe) and the hundreds of files of generated code that result from processing the Collada schema. In my opinion it isn't worth it, but that's certainly debatable and I accept that a reasonable person could have a different view.

    ...however, all of that is from C/C++ and not .NET, so its not really relevant to this discussion because we are talking about .NET
    I don't see how this discussion is language specific at all.

  8. #18
    Junior Member
    Join Date
    Sep 2008
    Posts
    5
    Quote Originally Posted by sthomas
    I have to convert "1 2 3 4" into an array of integers, but I don't have to parse the xml markup manually at all.
    But you have to do much more than that. You have to encode all the knowledge of which nodes are allowed as children, which attributes apply to which node types, which values are enums, which are strings, which are ints, which are floats, which are lists of ints, which are lists of floats, etc. Collada is not exactly a trivial schema to handle, even if the low-level "I read the start of a tag, its called instance_geometry, it has these attributes and these child nodes" business is handled for you by a generic Xml parser.

    Xsd's processing of the schema handles all of that stuff for you. You don't need to code all of that yourself.

    Now the question is if the extra convenience provided by the code generator (it'll automatically convert "1 2 3 4" into an array of ints) is worth the hassle of dealing with the code generator (and it's bugs, like the one you're trying to work around in xsd.exe)
    First, as I've already said above, its doing a lot more than just parsing "1 2 3 4" into an array of ints. Second, it strictly speaking isn't a bug in xsd.exe because its limited support for <group ref=""> schema tags is documented, even if it is annoying. Finally, the hundreds of files generated (assuming one per schema item) is exactly my point. If I can get something to generate the appropriate classes from the schema directly, then that's hundreds of files that I don't have to write. If you want to handle Collada in its full glory, then you need those hundreds of classes. If you just want to do a quick hack to extract some piece of information for your application, then you can scrape it out with any old Xml library, but your application will not be robust in terms of the variety of collada files that are legitimate vs. the variety of files your application can eat with its limited hand-crafted Xml scraper. By the time you go through all the work of hand-crafting all the support in the Collada schema, then you have just duplicated the hundreds of classes generated by Xsd.

    [quote:i01p8k8z]...however, all of that is from C/C++ and not .NET, so its not really relevant to this discussion because we are talking about .NET
    I don't see how this discussion is language specific at all.[/quote:i01p8k8z]

    .NET isn't a language, its a platform. Xsd can output the generated source in C# or in VB.NET or in a number of other languages. My comments are not related to a specific language, but to the fact that .NET provides an infrastructure for Xml marshalling and unmarshalling already. The easiest way to utilize that infrastructure from a schema document is to use Xsd to generate the classes instead of writing them by hand.

    However, even if you were to decide to write your own data binding by hand, it would be lots more work to use XmlDocument, etc., classes instead of using Xml serialization. All the existing bindings for .NET that I can find out there do things the hard way by manually scraping stuff out of the XmlDocument, but they don't add any value over what the Xml serialization classes would have gotten you in the first place. Furthermore, because those classes were not automatically generated from the schema, which is assumed to be correct, each one of those hand-written classes has to be unit tested and validated to give the correct results for the wide variety of valid collada inputs.

    Finally, if there is a bug in the schema and an updated schema is made available, if I can use xsd.exe then I can pick up those corrections automatically, otherwise I have to sift through the differences between the original and updated schemas and manually update my binding classes to incorporate those changes. Then I'll have to update my application functionality built on top fo the data binding, but I'd have to do this no matter what if the schema is updated and I want to support the updated schema. With Xsd, I have less work because I've automated part of the process.

  9. #19
    Senior Member
    Join Date
    Jan 2006
    Location
    Foster City, CA
    Posts
    540
    Second, it strictly speaking isn't a bug in xsd.exe because its limited support for <group ref=""> schema tags is documented, even if it is annoying.
    By your logic, any bug that has a bug report filed against it is no longer a bug since it's documented. Call it whatever you want, but it's a defect of their product that you now have to work around.
    Finally, the hundreds of files generated (assuming one per schema item) is exactly my point. If I can get something to generate the appropriate classes from the schema directly, then that's hundreds of files that I don't have to write.
    Ah, this is the heart of our disagreement then. You view these files as necessary whereas I don't.

    Let's say I wanted to write a lib to import Collada into my rendering engine. I would break this down as involving three tasks:

    (1) Load and parse the xml (15%)
    (2) Serialize the string data to native language types (5%)
    (3) Convert Collada's data structures to my rendering engine's data structures (80%)

    I've also written my estimation of how much of the whole project each task would take. For loading and parsing the xml I'm going to use a library, so that's not an issue. From my perspective, the only thing schema generated code would save me is the serializing to/from native language types, but that represents a tiny part of the overall work, so it doesn't seem like a big win at all.

    I imagine your perspective of the workload is different:

    (1) Write a class data binding for every type in the schema. This data binding handles both parsing the xml and converting to native language types. (90%)
    (2) Convert Collada's data structures to my rendering engine's data structures (10%)

    Since you've already accepted that you need an xml data binding, your perspective on the workload is nothing like mine. Here there's much more work to be done overall than in my workload, but the code generator is taking on the vast majority of the work, so it seems extremely valuable. But just like in my workload, you still have to write the conversion from Collada to your engine. In either case this is where the bulk of your time will be spent. I'll need to spend a little extra time writing a few serialization routines, but I think that'll be outweighed by the extra time you have to spend working around bugs in the code generator and managing all the generated code files.

  10. #20
    Junior Member
    Join Date
    Sep 2008
    Posts
    5
    Let's say I wanted to write a lib to import Collada into my rendering engine.
    That is not what I'm doing, so its irrelevant to my needs.

    You imply once again that the only role played by the generated classes from xsd is to serialize the string data to native language types. However, I've already explained that there is much more going on than that, unless you really don't care about the Collada schema. A library that only parses XML doesn't know which nodes are allowed as child nodes, it doesn't know which attributes are allowed on which nodes and it doesn't know about the data types defined by the Collada schema.

    I imagine your perspective of the workload is different:
    Sorry, but your imagining is also incorrect.

Page 2 of 3 FirstFirst 123 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •