Re: [xsl] IGNORE CASE IN XSLT

[Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>]

Hi Geert,

At 01:16 AM 12/2/2004, you wrote:
> > > It will not help a lot if one cannot predict the use of case in element 
> > > names. :-( Especially documents that originate from HTML of SGML have 
> > > this problem, as HTML and SGML are case insensitive...
> > >
> > > It even gets worse if you have to account for ancestors as wel... :-(
> > >
> > > It would have been nice if the XSL standard would have provided a case 
> > > sensitivity option. But on the other hand, it is actually more a job for 
> > > XML parsers. Are there XML Parsers that have an option to ignore case of 
> > > the input? (not using a declaration file)
> > Not as such (such would be an XML+ parser of a kind, not a conformant XML 
> > processor), though you might be able to use an SGML parser.
>
> 2nd person to mention this..
>
> XML+ yes, but I wouldn't say that the parser is violating the 
> recommendation. It is an option, so it is up to the user to violate the 
> XML rec...

Yes, quite true, and certainly the case of a super-functional tool (an XML 
parser plus other features) is an interesting one to consider when trying 
to define "conformance".

A strict definition of conformance that says "what the XML Rec describes, 
and no more" is important to maintain if only so we avoid the situation 
where, say, BigSoft Corporation releases an "XML processor" that supports 
non-standard features, such as (say) SGML tag minimization. Then the market 
starts working with tag-minimized non-XML. If a significant portion of the 
market then locks into this, BigSoft's competitors have to match this 
feature, and pretty soon it's not at all clear that tag minimization is 
non-standard.

Note this phenomenon is not less dangerous, but rather more so, when the 
feature is one that the market (or part of the market) really wants. That 
is, it has nothing directly to do with the technical merits.

The good side of this is that it represents, arguably, evolutionary 
pressure on the standards to give the market what it wants. The bad side is 
that it may put BigSoft in the position of dictating what the actual 
standard is.

This is why standards hawks such as myself are so guarded about 
non-standard features. Labelling them as such, by saying "this includes an 
XML processor but has some extensions and non-standard features" helps a lot.

> Reconsidering my remarks, I don't think the ignore-case option is 
> sufficient. Too often SGML and HTML are not well-formed. One indeed would 
> be better off with an SGML parser.

It depends on the case, as you'll surely agree. In this case, IIRC the OP 
wanted to map "italic" and "ITALIC" to "i" (not simply case-folding), but 
didn't have to worry about well-formedness.

Cheers,
Wendell


======================================================================
Wendell Piez                            mailto:wapiez@xxxxxxxxxxxxxxxx
Mulberry Technologies, Inc.                http://www.mulberrytech.com
17 West Jefferson Street                    Direct Phone: 301/315-9635
Suite 207                                          Phone: 301/315-9631
Rockville, MD  20850                                 Fax: 301/315-8285
----------------------------------------------------------------------
  Mulberry Technologies: A Consultancy Specializing in SGML and XML
======================================================================