Subject:Restricted Mixed Content Author:(Deleted User) Date:29 Feb 2008 02:14 AM
Hi Daniel,
unless the two versions of <data> occur inside different elements, you cannot have two definitions for the same element name. You could allow both contents as optional, but in this case you would not be able to avoid to have both forms at the same time (or none)
Subject:Restricted Mixed Content Author:Daniel Pontzer Date:29 Feb 2008 08:23 AM
Thanks, Alberto, for your prompt response ... if not obvious, my interest was in backward compatibility. In my business, as our target hardware gets more complicated, parameters that were once simple tend to take on more 'dimensionality'. I'd like to be able to support old and new versions of those parameters so old versions of the XML file don't have to be updated to work in the new environment. Can you provide guidance or point me to any white paper that might cover this topic? I'd hate to modify to schema to handle a new element that is in parallel to the original 'data' because that would be distasteful from the perspective of naming the new element since it is essentially the same parameter as the original except that it has gained a dimension. I would analogize this problem to that solved by an overloaded function call that can take on any of N different types of argument lists. Is there no equivalent capability in XML Schema?
Thanks,
Dan Pontzer
(attempting to drag my colleges into the 21st century ... we're way behind the times as far as use of XML goes. The moment I learned about XML (just last year) I saw its practicality and wondered why our software department hasn't been promoting its use. Mostly we do embedded software so were not so 'up to speed' on web stuff which is where XML came from, of course, but its practicality is so far ranging outside of the web)
But in order to have a definition to match both cases, you could add a mixed="true" to the xs:complexType definition, but this would allow any text between the <cell> elements (without checking if they are one or more numbers).
Another attempts could be extending the "vector" type with child nodes:
but this grammar would be invalid as there cannot be two elements with the same name but different types in the same scope.
The only valid alternative would be to require each <data> element in the XML to have an xsi:type attribute to signal which type should be used to validate it: