Hi Wendell,
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".
:-D
*a long thread about 'named character references' pops into Geerts mind*
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.
Err..
I'm not sure what point you try to make, but I am definitely not pro-minimization of tags (apart
from <elem />). I think well-formedness was a great idea. :-)
Could it only be possible to travel back in time and prevent the SGML inventers of adding the
tag-minimization feature of SGML (and HTML)... *sigh*
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.
Uhm... (getting a bit sleepy over here, sorry)
It is nice when the market shows that a standard lacks something, but nicer when it is incorporated
in the next version. Good thing so much effort being put into XSLT and XPath 2...
And no, I don't think that many people need that ignore-case option. But it might have been helpfull
to me.. ;)
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.
Ah well, I was reflecting on projects I have done in the past, which have had to do to many times
with converting legacy data (SGML/HTML as well) to XML. I wasn't very clear about that I guess.
Never mind...
Cheers
--~------------------------------------------------------------------
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>
--~--