Community
Participate
Working Groups
Ed, I might be willing to lend a finger or two to this effort. Xerces is investigating 1.1 support as well.
Ed, I am also willing to help with this. Should this effort get started, the WTP XML Schema editor could be an early adopter/proving ground. I wonder if there's some nice value add for the Modelling world in mapping the XML Schema 1.1 cross constraints to some structural model constraints (OCL, others).
Xerces will have 1.1 support. I know that there are a couple of new data types that have been added from my work with the XPath 2.0 data model which leverages the XML Schemas 1.1 data model. Xerces is planning a possible December time frame for their implementation. I might have need of this for WTP interfacing with the XPath 2.0 Schema Aware processor we are building as well.
Shouldn't this be split/spun-off into multiple bugs, one for the XSD model and one for any mapping/serialization support for ECore? I can see the value in just having the model bits in place without the runtime part, e.g. to support the WTP editor, or even to be able to read schemas in a version-sensitive manner.
Once the 1.1 work is done, we'd look at the impact this has on the XML Schema to Ecore mapping, but there's little point in planning ahead for that work when this complex task seems so unlikely to make progress anytime soon.
(In reply to comment #5) > Once the 1.1 work is done, we'd look at the impact this has on the XML Schema > to Ecore mapping, but there's little point in planning ahead for that work when > this complex task seems so unlikely to make progress anytime soon. Actually this is closer to reality than you think. It has been in Candidate Recommendation since May, and I would suspect sometime next year for it to be a recommendation. Xerces-J will have XML Schemas 1.1 support within the next week or so with their 2.10.x release. Once this hits Xerces-J, end users and adopters are going to start to want to have this functionality. http://www.w3.org/News/2009#item69
My comment was about the likelihood of someone not just wanting it but wanting to do all the work to make it happen in the XSD model. IBM seemed disinclined to invest resource into this at the time I was employed there; maybe that will change once there's runtime support for it and customers start to ask for it.
(In reply to comment #7) > My comment was about the likelihood of someone not just wanting it but wanting > to do all the work to make it happen in the XSD model. IBM seemed disinclined > to invest resource into this at the time I was employed there; maybe that will > change once there's runtime support for it and customers start to ask for it. Agreed...and I don't think we should wait for IBM in order to take the initiative to make it happen. Understand that I'm not asking for Ed to do all the work, I think it has to be a community effort. Once Xerces-J is out, I suspect the drum beat to increase for support in the various eclipse tooling.
We'll need a hard working contributor with in-depth schema and modeling knowledge.
I'm copying wst.xsl's resident XML Schemas 1.1 expert on this, Mukul. He's also a Xerces-J committer and worked directly on the XML Schemas Assertions implementation in the upcomming release. He's also a wtp source editing committer as well.
(In reply to comment #9) > We'll need a hard working contributor with in-depth schema and modeling > knowledge. I'm only fifty percent of that: spare-time contributor with a reasonable knowledge og both schema and Ecore (you've seen my patches, Ed) but I'd volunteer...
Volunteers are warmly welcomed!
I would like to volunteer the examination phase of each of the major Schema 1.1 features, beginning in earnest mid-spring (after M6 and M7 of Helios). I tried, just for kicks, to add the 'assert' element from XML Schema 1.1 into the existing ECore model and consequently the way the EMF model loads/saves from/to a DOM. It took 5-6 units of 'fun time' (a unit of fun time is apprx. 21 minutes, the length of my train commute each way using http://m.dk/), as I had to grasp the way construction, reconciliation and analysis is performed in the XSD model. I think I get it now, but adding stuff to the model is not exactly a picnic. My general idea is to examine each feature: - assert - alternative - error - assertion facet - defaultAttributes - all - openContent - targetNamespace (on an element declaration) - override - inheritable attributes - new datatypes (precisionDecimal, anyAtomicType, etc) - new facets With all that in the model, it is then possible to support the functionality in other areas of Eclipse (in my personal order of importance): - In-model diagnostics - WTP schema validator - WTP schema editor - xsd2ecore mapping tools + more annotations if needed - XMLSave/Load using these annotations (PhychoPath2 will come in handy here, to resolve type alternatives) I'm sure I'm missing something on that list, but it's a start. If the owners agree, I'm going to open bugs for XSD model 1.1 and subtasks to track the progress of each of the 1.1 features. I'm hoping I won't be the only volunteer for this, otherwise it won't get done, but I'm hoping that picking away at the tasks will pique the interest of any schema lurkers out there.
I think I'm the only one who needs to agree and you have my complete support! The existing model is maintained as a Rose model, but that's too horrible. It would be nice to have Ecore Tools diagrams like the old ones, but that's a pretty big task too. Not an absolute requirement but very nice...
