[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] Proposal for DITA namespaces
> -----Original Message----- > From: Eliot Kimber [mailto:ekimber@innodata-isogen.com] > Sent: Tuesday, 2004 August 03 13:26 > To: dita@lists.oasis-open.org > Cc: Paul Grosso > Subject: Re: [dita] Proposal for DITA namespaces > > [lots of good stuff from both Eliot and me elided...] Don't people have XSLT that handles DITA now? I know our customers do. And, while I know DITA XSLT keys in a lot on the values in the class attribute, don't DITA XSLT stylesheets ever refer to an element or attribute name in any of their match or select patterns? Because, if they do, they will all break when you put a namespace on the DITA vocabulary. An XPath pattern such as match="foo" will NOT match the element "foo" if foo is in a namespace (even a default namespace). Now I know about local-name() and all that, and I'd be interested in researching how best to make use of such things in a post-1.0 DITA (because I too think DITA should eventually be in a namespace with a schema), but I think putting any namespaces on DITA now is going to break too many existing applications out there. My urging to the TC is to push these interesting innovations off to post-1.0, cut through our issues with more dispatch (how much longer can we discuss tables !?!), and get DITA 1.0 out there before the excitement we've managed to build fades. The sooner we do that, the sooner we can move on to solving the next set of issues such as these that will help Eliot's users. I have seen way too often committees take too big a bite and then come out with something too complicated too late rather than putting an early stake in the ground and then responding to user-requested enhancements in a timely revision. paul
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]