OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [dita] Proposal for generalized attribute addition

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:mpriestl@ca.ibm.com]
Sent: Tuesday, August 02, 2005 12:59 PM
To: Paul Prescod
Cc: dita@lists.oasis-open.org
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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]