On Fri, Dec 11, 2009 at 11:46 AM, Stian Soiland-Reyes <[email protected]> wrote: > On Fri, Dec 11, 2009 at 10:32, Egon Willighagen > <[email protected]> wrote: > >> But that would also be achieved if you would not use a NS prefix at all... >> not? > > yes, but then you could no longer have a target namespace in the > schema definition, and the XML would no longer be > 'semi-self-documenting' of what kind of XML document it is.
Sorry... you lost me. The NS would be the same, and the document would still be in the same NS. You just would not tie it to a prefix. >> That sounds like one more reason for not using tools like XMLBeans :) >> Never really liked them. > > I disagree, I think we should all use these tools when you are the > official generator or reader of some XML which you (should have) > described in a schema - that assures you (to a reasonable degree) that > you complying with your own schema. Not trying the discourage you of using it. Validation allows ensuring sticking to the schema too. > For instance our current .t2flow format has an XSD that I > back-generated, but I'm still not sure if it is correct because the > .t2flow serialisation and deserialisation code just does various DOM > manipulations. > > As for the plugins.xml - the format used to be just <plugins><plugin> yes, as in Taverna 2.0. > and manual DOMs, so when I XMLBeanified it I wanted it to be backwards > compatible, but still introducing a namespace and a schema.. So we > ended up with this half-solution :-) OK. >> What I don't get about this statement is that all elements are >> 'namespaced' anyway... it's just that some may have a "" namespace... >> I do not know how XMLBeans addresses that, and perhaps its limitations >> indeed require the unqualified trick... > > I think it gets slightly tricky as you generated packages of beans per > namespace, and different formats in the blank namespace might then > come in conflict with each other. Ah, yes, that could explain it. > I've not examined in details, there might be ways around that by > specifying a mapping. I found it easier to enforce the namespace.. > > I also generally like just simplifying with xmlns="http://..."; - but > there are some awkwards with that, we could not do it in .t2flow for > instance, as this would also affect the serialisation of the service > configurations, which might genuinely have to be in the empty > namespace. There's also questions of what namespace the attributes > would then be in, and that you could no longer use the prefix in > attribute values. Yes, that's a true downside of XML... attributes are not defined to be in the same namespace as the element to which they belong... Again, I am not trying to say the approach is wrong... just interested in the reason of why :) Egon -- Post-doc @ Uppsala University Homepage: http://egonw.github.com/ Blog: http://chem-bla-ics.blogspot.com/ PubList: http://www.citeulike.org/user/egonw/tag/papers ------------------------------------------------------------------------------ Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev _______________________________________________ taverna-hackers mailing list [email protected] Web site: http://www.taverna.org.uk Mailing lists: http://www.taverna.org.uk/taverna-mailing-lists/ Developers Guide: http://www.mygrid.org.uk/tools/developer-information
