yes, in XSLT 1.0 you'd have to rely upon
contains(), substring-before(), and substring-after() fed through
recursive templates - but it' should be doable
Paul Prescod wrote:
A
restriction to tokenized values seems
quite severe to me. No CDATA attributes? No URLs?
Even under
my proposal “meta”
and “props” would share the same model.
In XSLT 2.0
I’m pretty sure that
they could be unified at the code level as well.
In XSLT 1.0
I’m not as sure. I admit
that all of the parsing, splitting and unescaping would get pretty ugly
in XSLT
1.0. It might be easier to handle after pre-processing or through
extension
functions.
From: Michael
Priestley [mailto:]
Sent: Tuesday, August
02, 2005
12:59 PM
To: Paul Prescod
Cc:
Subject: Re: [dita]
Proposal for
generalized attribute addition
I was thinking roughly the same thing, although perhaps with "meta"
as the generic ancestor, parallel with "props". If we are
willing to restrict the normal content of "meta" to be simple tokens
(ie simply don't allow parentheses except in the generalized form) then
we
could use the exact same model for generalizing/roundtripping both
attributes.
Effectively we'd have one generic ancestor attribute for conditional
processing
attributes, and one for anything else. They could also share the same
XSLT
library for unpacking the conditions if processing is desired in the
generalized form (any process that can't handle the generalized form
would be
considered specialization-unaware).
Michael Priestley
