[
Lists Home |
Date Index |
Thread Index
]
> > I'm not entirely sure what the objection to this is.
> Wouldn't it make more
> > sense to default an empty element than to insert the
> element automatically
> > (which could be taken care of by setting the minimum
> occurrence to one)?
>
> How would setting the minimum occurrence to one automatically
> insert the
> element along with its value?
Well, we're supposing that there are two alternatives for element defaulting
(besides just ditching the whole idea): 1) default empty elements or 2)
default non-present elements. If the latter is desired, it can be
"simulated" with the former by setting the minimum occurrence value to one.
> Support for attribute defaulting is arguably desirable
> because there is a
> long-established practice of doing it and people have got
> used to depending
> on it. There is no such well-established practice for
> element defaulting.
> What is the compelling use case for being able to specify an
> empty element
> in the instance and have the validator insert a value specified in the
> schema? This is not at all the same kind of thing as
> attribute defaulting
> and the existing practice of attribute defaulting provides no
> justification
> for such a feature. Why should this one particular kind of
> transformation be
> specified in a schema?
I guess the only case for this is that elements should be on the same
footing as attributes. Anyway, I've been pretty much convinced by the notion
that the "special status" of attribute defaulting is an unfortunately
vestige of older markup variants (not mentioning any names here) and should
be replaced by a general purpose transformation approach.
Matt
|
