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] Issue With Requirement for Trailing Space in class= Values


Wouldn't adding a non-name trailing character to the class attribute
value cause problems for processors that care about the specific
position of the item within the class attribute? Some processors may
look for the last topic/element token or for the second to last. Or for
processors that are generalizing a DITA document since you might mistake
the character as the last token and end up generalizing an element to
itself?

Are the attribute values that have the trailing space stripped present
in the document instance? Aren't the class attribute values typically in
the DTD or schema rather than the instance?  I can't imagine that
MarkLogic is "correcting" the DTD or schema (but what do I know?). Is
using the default class attribute value from the DTD or schema a way out
of this problem?

   -Jeff

> -----Original Message-----
> From: Eliot Kimber [mailto:ekimber@reallysi.com]
> Sent: Friday, March 07, 2008 12:42 PM
> To: dita@lists.oasis-open.org
> Subject: [dita] Issue With Requirement for Trailing Space in class=
Values
> 
> In the process of implementing DITA support in our RSuite product, we
> discovered that the current version of the MarkLogic XML repository
> strips trailing spaces from attribute values. This of course breaks
all
> hope of generic DITA processing unless we implement a workaround in
> advance of MarkLogic fixing their bug (which they might refuse to
fix).
> 
> One obvious solution would be to allow or require a trailing non-blank
> character, e.g. "+" or "^" or something equally non-name-characterish
> that prevents the problem.
> 
> So several questions:
> 
> - Does anyone know of any processors that would break if class= had a
> trailing non-blank character. Certainly no processor matching on "
> module/type " would. The only case I can think of would be one that
> blindly concatenated class= values for some reason but I can't think
of
> why anyone would do that.
> 
> - Would it be possible to make this spec change for 1.2 if there was
> consensus that is was a good idea? I think it would be of value
because
> it would remove a serious source of both surprise and user error and
> generally avoid the possibility of this sort of "who would ever make
> processing depend on trailing white space?" processing result.
> 
> Of course the character's use would have to be option for backward
> compatibility but that should be no problem--just have to make it
clear
> that there should be no Simon Says behavior if the character is or is
> not there.
> 
> For our product we have no short-term choice but to add the trailing
> blank on import of known DITA content but our question will be whether
> we have a hard requirement to strip it back out on export.
> 
> Cheers,
> 
> Eliot
> 
> --
> Eliot Kimber
> Senior Solutions Architect
> "Bringing Strategy, Content, and Technology Together"
> Main: 610.631.6770
> www.reallysi.com
> www.rsuitecms.com
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php



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