I'm coming late to the party. I can see both sides of this debate. I'd be much happier if tool vendors were willing and able to support something more flexible. In fact, if I had my druthers, I'd propose an extension to James' schemas.xml file that could match on a PI, then we wouldn't need to standardize any PIs. That and some UI widgets to allow users to edit that file and I think we'd cover all the use cases.
But it seems to me that, if tool vendors are going to use a PI for
this purpose, the community will be better off if there's exactly one
PI and not one PI for each tool with similar but not identical syntax
and semantics. Especially if that PI can have a syntax and semantics
that encourages authors to think about what it means to have different
schemas for different applications.
I agree with Jirka's comment that the draft needs to describe the
applications that might care about the schema in more general terms;
it's not just for validation.
I also think, if we're going to do this, we should put on our asbestos
underwear and assert that the PI is named "schema". Let's (a) avoid
endless debate about whether it's appropriate to use this PI for
non-OASIS schema languages and (b) dissuade anyone from proposing that
we need ?w3c-schema and ?iso-schema, etc.
But I wouldn't lose any sleep if we decided to try to persuade tools
vendors to do something else instead. (Of course, we might want to
standardize *that* too which would be a little more work.)
Be seeing you,
norm
--
Norman Walsh <[EMAIL PROTECTED]> | If today was a fish, I'd throw it back
http://nwalsh.com/ | in.
pgpTNij5YHRll.pgp
Description: PGP signature
