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(_at_)mulberrytech(_dot_)com
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
======================================================================
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--