Jirka/Ken
Thanks for your comments
Ken wrote
> I understood you earlier to say that you wanted a DSRL
> instruction that changed the prefix but *not* the namespace URI, and my
> only warning was that if you do so then namespace-qualified names in
> attribute value contexts would lose their prefix declarations because
> DSRL doesn't know (and can't know) what attributes to change.
Jirka wrote:
This is a very important (and evil) issue. If there will be prefix
rename feature in the DSRL, the stadard should at least clearly state
that this renaming is not operating on QNames in attribute values and
element content and that the result of renaming can produce illegal
output if there are such QNames.
Yes, the attribute problem scares me silly, especially when it comes to
elements with a mix of namespaed and non-namespaved attributes such as (not
that this is a valid example)
<dsrl:my-element id="abc" dsrl:attribute="true">
where the unqualified attribute is associated (indirectly) with the
namespace of the parent element.
We might be able to get away be stating that what we are doing is a direct
transformation of "name tokens" for attribute names, e.g.saying that a
mapping from dsrl:attribute to a:attribute will be treated as an exchange of
tokens not qualified names, but this gets messy at DOM level. Must think
further on this. Keep the thoughts coming, they do help.
Ken also commented:
> But, I'm willing to drop my concerns if no-one else thinks this is an
> important issue.
I suspect others have concerns as well (not less myself) but at least Alex
and myself see a use case for such functionality, even if we do not know how
to safely implement it.
Martin
-- DSDL members discussion list To unsubscribe, please send a message with the command "unsubscribe" to dsdl-discuss-request@dsdl.org (mailto:dsdl-discuss-request@dsdl.org?Subject=unsubscribe)Received on Fri Dec 9 09:13:14 2005
This archive was generated by hypermail 2.1.8 : Fri Dec 09 2005 - 10:03:01 UTC