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] Potential Missing Feature for Inline SVG: Display Width and Height


Actually, I agree with suggestion number 1 since other use cases are possible for specializing foreign as a container for inlined vocabularies that need to behave like images when rendered. This element is our closest match to the behaviors you could get in SGML with data notations, where you could pass in this kind of contextually-needful info for use by the processor that would actually embed the data object into the result view. It's just that DITA does not have a nice general way to add any old property, as Eliot noted. I lean towards making the solution easy for authors. This element interfaces the other vocabularies into the DITA rendering context, so it is most like <image> in that regard. But since we can't use <image> as the specialization base for SVG, Eliot's #1 solution is the nearest surrogate.

I have often struggled with the pure objective of total separation of presentational data from XML. If DITA were a pure abstraction of a data model, that would be  key goal indeed. But DITA is more like HTML in that it is primarily a means for representing content for publication, and in both languages, there is no graceful way to associate instance-specific display properties (unlike outputclass which applies to every use of an element) without making those properties part of the element instance itself. It is a matter of both ease of management and the reality that we are not really specializing pure abstractions--we are mapping abstract forms to DITA, which always adds its own baggage to any purely abstract or semantic model. Hence the reason why we see display-atts in other elements.

As this applies to Eliot's suggestion, I would just add display-atts into foreign so that it can be more "in family" with those elements (meaning processors can use common code for all cases).
--
Don
 
On 5/17/2015 9:13 AM, Eliot Kimber wrote:
In implementing output processing for inline/referenced SVG for DITA 1.3
I've discovered that there's a small missing feature, namely the ability
to specify an explicit width and/or height for the SVG.
...
I think this means that we need to define a way for DITA document authors
to specify explicit width and height for inline SVG graphics.

I see these possible solutions:

1. Add @width and @height to <foreign>. This is an architectural change
but would be easy to implement and is backward compatible. It would be
useful for any use of foreign to contain data for which a width or height
is meaningful.

2. Define specializations of <data> for use within <svg-container> (or
within <foreign> generally) that specify width and height, e.g.:

<svg-container>
<display-width value="2in"/>
<display-height value="2in"/>
<svg:svg>...</svg:svg>
</svg-container>

This requires no architectural change but is slightly less convenient to
author.

3. Do nothing and let the community define a convention that would be very
much like option (2) or possibly some use of processing instructions but
would not be part of the standard.

I think I prefer option (1): It's simple and obvious and doesn't break
anything. It makes <foreign> used for graphical data more parallel with
<image> and doesn't risk tagname conflicts with existing custom domains.
It would not require new element reference entries.



--
Don R. Day
Founding Chair, OASIS DITA Technical Committee
LinkedIn: donrday   Twitter: @donrday
About.me: Don R. Day   Skype: don.r.day
"Where is the wisdom we have lost in knowledge?
Where is the knowledge we have lost in information?"
--T.S. Eliot



Avast logo

This email has been checked for viruses by Avast antivirus software.
www.avast.com




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