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


 

> -----Original Message-----
> From: Eliot Kimber [mailto:ekimber@reallysi.com] 
> Sent: Friday, 2008 March 07 22:33
> To: Ogden, Jeff
> Cc: dita@lists.oasis-open.org
> Subject: Re: [dita] Issue With Requirement for Trailing Space 
> in class= Values
> 
> Ogden, Jeff wrote:
> > 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?
> 
> I suppose those could be problems--hadn't considered checks that look 
> for the last non-blank token. That would certainly be a compatibility 
> issue.  Hmph.
> 
> Is there some history for why the trailing blank design was 
> chosen over 
> a trailing non-blank? People have already asked me and I 
> wasn't involved 
> with DITA when that decision was made but I assume it was not made 
> without appropriate consideration.

It was made back in pre-OASIS days to make it easier for
the XSLT to parse the class attribute.  

When DITA first came to OASIS, I argued that computers were 
supposed to relieve humans of insignificant details like 
the exact number and placement of blanks in expressions, and
that we shouldn't require anything specific about trailing
blanks.  I figure we should allow what XML would call S+ between
tokens and S* at the beginning and end of the class attribute
value and leave it to the implementations to deal with such 
details.  But I was overridden in favor of ease of implementation.

I have to say that you are now asking for yet more concessions
in favor of ease of processing over the ideal situation, and
much as I have sympathy for your plight, it doesn't sound like
the right way to go to me.

paul


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