Bug 342887

Comment 1 Ed Merks 2011-04-14 17:28:13 EDT

I'm not likely to ever find time for this.  In my opinion, there's really very little value to be gained. Almost none.  I don't think these things would end up influencing how things are serialized rather only affect what's considered valid.

If you hope for someone to look at it one day, I'd suggest providing much more information.  I.e., an example schema, example serializations, what type of serialization you're hoping to get as opposed to what you actually get now, and so on.  I don't even recall the details of the thread and you've not even provided a link to it.

Without more details, I'll just return it as won't fix.

Comment 2 Piotr Przybylski 2011-04-17 06:59:23 EDT

The starting point was that its useful to keep 'block/blockDefault' information in the model since it is present in industry standard schema, for example many of the STAR (Standards in Technology for Automotive Retail) XSDs (1), one of which I attached]. When object based on this schema is custom serialized, knowing whether blockDefaults is defined is needed to make it correct. I am not sure how it influences standard serialization, I only assumed it does since the XSDSchema implementation uses it [e.g. XSDSchema.getBlockDefault()]. The discussion I was referring to is [2]

[1]
http://www.starstandard.org/uploads/SIGXMLSTAR5/STARSchemaRepository_Rev534.zip

[2] - http://www.eclipse.org/forums/index.php?t=msg&th=136663&start=0&S=fce8d57cda7aebf2726d265801b90e90

Comment 3 Piotr Przybylski 2011-04-17 07:00:24 EDT

Created attachment 193430 [details]
Industry standard STAR schema with blockDefault

Comment 4 Ed Merks 2011-04-17 12:05:42 EDT

It would be far better if you provided a test case where EMF produces an invalid serialization.  You're making an assumption that block will somehow help produce a correct serialization, but I don't see how that assumption is valid and in fact I don't believe it is. You've certainly not demonstrated a basis for that assumption.  So rather than implement a feature that I have no idea will do anything useful, I'll ask you to provide an actual test case that produces an invalid serialization so that I can focus on what's wrong rather than chase what may turn out to be a baseless assumption.  After all, you state in the newsgroup thread "you are absolutely right, the xsi:type is not generated by the api" so I don't really know what is generating it, if not EMF's API, but you'll need to show me with actual code, rather than English words. 

On the one hand, if the xsi:type isn't needed, EMF shouldn't be producing it, regardless of whether xsi:type is blocked; that's a problem I'll be happy to fix.  Other the other hand, if the xsi:type is needed, then EMF is right to produce it, even if that's in violation of the block directive.  I.e., the schema might be so restrictive it's not possible to produce a valid serialization of an instance.  Someone will need to fix the schema in that case.

Comment 5 Ed Merks 2011-05-12 15:19:37 EDT

I can't imagine ever finding time for this nor do I think it will solve any problems if I did.  If there's some bug to be addressed (EMF isn't producing a correct serialization), I'd be happy to look at a self-contained test case demonstrating the issue.