On 2010-10-08T18:11:06, Dejan Muhamedagic <[email protected]> wrote:
> > Admittedly, I find the whole notion of "ordered" collocation extremely
> > annoying, and unclean design. I'd much rather not have the shell support
> > that at all.
> I don't like the thing either. But how/what should then the
> shell support in terms of collocation?
"Not at all", and the 1.2/1.1 schema could contain some XSLT that gets
executed on upgrade to the new version that rewrites this to distinct
ordered/collocation sets.
(Either that, or the shell could.)
(We don't expose _all_ XML features anyway; in this case, we wouldn't
consider it a problem of missing features, but a design choice to unify
the shell syntax, and phase it out in the schema too. If users insist on
using it, they'd get the XML object dumped; no harm done.)
What I'm trying to say is that we don't _have_ to be stuck with things
that _can_ uniquely be transformed to a cleaner syntax; compared to what
the XSLT did for 0.6 -> 1.0, this is trivial.
Obviously we wouldn't want to do this carelessly and frequently, but
going to the next schema revision we could consider it?
> > For order + colocation, a rather common combination of constraints, what
> > I'd rather have the shell do is detect a match between them and merge
> > them in the shell syntax - there's no reason why a shell statement
> > _must_ only expand to a single XML element.
> Agreed. Though so far all shell constructs have a single element
> XML production. What I meant to say is that we'd need a bit of
> work for that, and it doesn't look very straightforward to me, at
> least not now.
Agreed - I respect that this would be a quite substantial amount of
work, but definitely something to keep in mind. It doesn't have to
happen tomorrow, but we plan to have the shell around for a longer time
;-)
Regards,
Lars
--
Architect Storage/HA, OPS Engineering, Novell, Inc.
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde
_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
