Jelks Cabaniss <[EMAIL PROTECTED]> writes: > I'd probably argue against any "official" standard (OASIS/ISO/W3C etc.) for > something like this. But as Jirka, Eric, David and others have clearly > stated, an agreed-upon convention could hardly do harm.
It could do a lot of harm, actually. > If EXSLT and SAX end up on client checklists, said clients > either have a specific use-case scenario or a mental fog > problem. Sorry, but I do not find this schema-association PI to be analogous to EXSLT and SAX. I think a reasonable person might not be considered too out of line if he or she were to describe this PI as a kludge. I don't think anybody would describe the EXSLT effort or SAX as a kludge. > How could a, say, "through this list" agreed-upon PI do harm? Because once it gets published, there is a risk of it becoming adopted by others as policy -- despite whatever admonitions you might put into to discourage anyone from treating it as such. See Tommie's comments earlier in the thread about that. When some tool developers add support for it and others don't, users start asking, "Hey, when I use tool X (which supports the PI), things work the way I expect, but when I use tool Y (which does not support the PI), things don't work the way I expect." So, to the user, tool Y is broken. And that user will post bug reports and mailing-list messages asserting that tool Y is broken, despite whatever admonition might be in the published "informal community agreement" that documents the PI (which document the user will have never actually read and will never read). > PS. Then again, I'm not PI-allergic. Indeed, some of us are dismayed that > (for example) for DTD-less ID recognition we're now going to be herded into > a hard-coded, goofy-looking "xml:id", intead of something like > > <?xml:id-attrs po-num id cust-num?> I have no idea what that is supposed to be, but if you intended it as an indirect way of providing support for the idea that a schema-association PI would be better than the alternatives, you've definitely made a point. > PPS. When convention becomes dogma, you *may* end up with a problem. > There's (unforutnately) no known cure for this -- in XML or any other arena. > But when the convention is not endowed with a "theological" imprint, the > likelihood of such happening is at least significantly diminished. In the world of software (as opposed to say, the Congregation for the Doctrine of the Faith), I do not know how conventions get "endowed with a theological imprint". But in the world of open-source/free software, how often do you see conventions (even "informal community agreements") *not* becoming dogma? --Mike
smime.p7s
Description: S/MIME cryptographic signature
