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: FW: Proposal: Vocabulary Module for SVG


Eliot,

I'm so pleased by this, and support your proposal so heartily that I want to begin to regularly attend DITA TC meetings - just to gain voting rights - in order to vote in favor.

Sadly the DITA TC meetings conflict with the XLIFF TC meeting. So I can only offer my enthusiastic endorsement. And I gladly offer any support in implementing (we've done similar SVG implementations - the theory works!).

Thanks,

Bryan
________________________________________
From: dita@lists.oasis-open.org [dita@lists.oasis-open.org] On Behalf Of Eliot Kimber [ekimber@rsicms.com]
Sent: Sunday, September 16, 2012 6:18 PM
To: dita
Subject: [dita] Proposal: Vocabulary Module for SVG

Don and I both thought I had already proposed this, but I couldn't find any
record of it. So I'm doing it now.

Proposal is:

Define a domain module that provides a specialization of <foreign>,
<svg_container> (or similar name) that allows a single <svg:svg> element as
its content.

I have implemented a working domain module and tested it with OxygenXML,
which supports inline SVG.

The benefit of this would be to enable use of inline SVG in DITA content
without the need to define such a module module locally. The module itself
is fairly trivial. Anyone who wanted inline SVG would have to define the
equivalent vocabulary module and there would be no reason I can think of for
it to be different from what I defined.

The main thing I noticed in implementing the module is that some of the SVG
element types' local names conflict with existing DITA tagnames, so the SVG
has to be namespace prefixed. That shouldn't be an issue in practice but it
needs to be documented as a limitation on the use of inline SVG, at least
for DTD-based documents.

Processors would need to be updated to handle inline SVG as an optional
feature. For the Toolkit this is pretty easy since most browsers support
inline SVG in HTML (and it's part of HTML5) and XSL Formatter and RenderX
XEP both support inline SVG (not sure about FOP).

Would also need to have the option of rendering inline SVG to images, which
wouldn't be too hard in the Open Toolkit context.

Cheers,

Eliot

--
Eliot Kimber
Senior Solutions Architect, RSI Content Solutions
"Bringing Strategy, Content, and Technology Together"
Main: 512.554.9368
www.rsicms.com
www.rsuitecms.com
Book: DITA For Practitioners, from XML Press,
http://xmlpress.net/publications/dita/practitioners-1/


---------------------------------------------------------------------
To unsubscribe, e-mail: dita-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: dita-help@lists.oasis-open.org





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