On Sat, Mar 29, 2014 at 2:05 PM, Abel Braaksma (Exselt)
<abel(_at_)exselt(_dot_)net> wrote:
2) the use-attribute-sets attribute
One answer suffices to illustrate my point which has got nothing to do
with undestanding or not understanding the semantics of copy and
copy-of.
This one is on xsl:copy, because xsl:copy allows the children to be
modified. The addition of use-attribute-sets serves the use-cases where
you want to replace or augment the attributes on a certain element.
It is not available on xsl:copy-of because the semantics of xsl:copy-of
are different: it makes an unchangeable deep-copy of the selected node.
Allowing use-attribute-sets would change that semantics, which is a bad
idea. If you want to change the children, use xsl:copy, not xsl:copy-of.
You have an option use-attribute-sets makes no sense in the context of
xsl:copy-of. So if it appears you just ignore it, perhaps with a
warning perhaps not.
You leave the content models the same and you only ever apply the
options that make sense for the variant you have chosen and you only
step in if what is specified would lead to an unresolvable ambiguity.
This is not an alien concept.
Take as an example the utility cURL. If I don't want the body of my
http request I specify HEAD instead of GET.
curl -v --request HEAD "http://www.guardian.com";
If I specify the content-type of the body with the --header option
curl -v --request HEAD "http://www.guardian.com"; --header
"Content-Type:text/xml"
There is no need to burden the user with a bazillion different
signatures or to officiously refuse to cooperate until the parameters
supplied are are in perfect semantic harmony.
cURL can still figure out what I want, it's still a HEAD request and
it still works.
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--