On Thursday, December 5, 2013 6:48 PM, Ate Douma <a...@douma.nu> wrote:
On 12/05/2013 11:26 PM, Woonsan Ko wrote: >> Hi, >> >> The current code is taking care of 'src' attribute for state, parallel, >> assign and invoke element. >> Invoke element should still accept 'src' attribute, but it seems to have >> been removed for the other elements in the current specification. > >The src atttribute for state and parallel was removed from the specification >several years ago, May 2010, with the suggestion to use the xinclude standard >instead. >See: http://www.w3.org/TR/2010/WD-scxml-20100513/#files Ah, thanks for the reference! We might probably want to know if the current implementation can support xinclude. > >> >> Do we need to deprecate (and remove later) the current behavior for those >> elements except of invoke element? >> Or is there still any good reason to keep the feature for some reason (e.g, >> overriding something from the 'src' for state/parallel element as a >> commons-scxml feature) ? > >Deprecate seems the reasonable thing to do as the xinclude solution is said to >provide a superior version of the same functionality. But that should be >validated and properly tested first before dropping the current >implementation. >But that shouldn't happen anyway until the next major release for SCXML, after >the 2.0 release. Surely we wouldn't want to drop those at this moment. Deprecation can be done though. > >Side note: the <data> and <script> elements also have optional usage of an >external src, not just <invoke>. Yeah, I was aware of that. I listed those elements from SCXMLReader code where I guess the *current code* takes care of 'src' attributes only for those listed elements. Cheers, Woonsan > >Ate > > >> >> Regards, >> >> Woonsan >> > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >For additional commands, e-mail: dev-h...@commons.apache.org > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
