RE: case-insensitive SF

[Kevin O'Kane <kevoka@AUTO-TROL.com>]

I agree with # 2 also.

Kevin

> -----Original Message-----
> From:	Dieter@isodraw.de [SMTP:Dieter@isodraw.de]
> Sent:	Tuesday, February 06, 2001 1:27 AM
> To:	Lofton Henderson; cgmopen-members@lists.oasis-open.org
> Subject:	Re: case-insensitive SF
> 
> Lofton,
>  
> good point. I agree with 2.
>  
> Dieter
>  
> 
> 	----- Original Message ----- 
> 	From: Lofton Henderson <mailto:lofton@rockynet.com> 
> 	To: cgmopen-members@lists.oasis-open.org
> <mailto:cgmopen-members@lists.oasis-open.org> 
> 	Sent: Tuesday, February 06, 2001 12:44 AM
> 	Subject: case-insensitive SF
> 
> 	CGM Open Members --
> 	
> 	In the teleconference for resolution of WebCGM Second Release
> issues, we decided that the "case-insensitive" spec for type SF,
> non-graphical text, T.14.5, was incorrect.  Specifically, it clashes with
> XML specifications and could make a real mess of attempting to implement a
> companion-file architecture.
> 	
> 	However, it has some impacts that we might not have intended.  For
> example, the ATA conformance test FNTLST04 contains this font list:
> 	
> 	1 >TiMeS_RomAN<
> 	2 >TIMES-italic<
> 	3 >helvetica-oblique<
> 	4 >courier-BOLD<
> 	
> 	This would now be invalid.  So the question we need to address is
> the scope of the correction.  Options:
> 	
> 	1. all SF parameters (telcon decision);
> 	2. all SF data in APS and APS attributes are case-sensitive, but
> elsewhere is case-insensitive.  (Note this leaves BegPic 'id'
> indeterminant, as it enters into fragment specifications).
> 	3. all SF parameters unless specifically excepted (e.g., could give
> exception to Font List, etc).
> 	
> 	I think #2 is a reasonable combination of minimal impact on legacy
> CGMs, and achieving what we intended with the correction.  
> 	
> 	Other thoughts?
> 	
> 	-Lofton.
> 	
> 	
>