Re: draft proposal for catalog resolution
On Mon, 31 Mar 1997 04:05:24 -0500 Martin Bryan said:
>I am having problems with understanding the following two productions in
>the draft proposals:
>catComment ::= '--*' (Char* - (Char* '*--' Char*) '*--'
>catKeyword ::= (Char* - (S | SystemLiteral | 'PUBLIC'
> | PublicID | catComment))
>Firstly, I cannot understand the Char* - part of theses productions. Why
>is the initial Char optional, and what role does the hyphen take? Is it
>the same as "-" or does it imply "NOT"?
Sorry for the confusion. This is a bit of notation the editors have
introduced into the XML spec to deal with the productions for comments,
PIs, etc. In the right hand side of a production, <code>a - b</code>
represents the set of strings which match expression 'a' and which
do NOT match expression 'b'. So
(Char* - (Char* '*--' Char*))
means 'any string not including "*--"' (or more pedantically,
any string matching Char*, but not matching (Char* '*--' Char*).
(There is a closing paren missing in the draft.)
>Secondly, what is the purpose of a catKeyword. I don't find the text
>>The catalog format is that defined by SGML Open Technical Resolution
>>9401:1995 (Amendment 1 to TR 9401), which
>>defines several keywords in addition to PUBLIC. These are matched by
>>the otherEntry rule, and may be ignored (or acted
>>on) by XML processors
>We should at very least list the keywords in the 1995 version of the TR,
>and ensure that the model in catKeyword matches this. (Can you really
The main problem with this is that TR9401 is built for extension and
allows keywords other than those defined in the spec itself. So
listing the keywords it does define won't do us much good. (Unless
the newest version changes this design.) You are certainly right
that we need to make sure the production for catKeyword matches
them correctly; it has some flaws in it that need fixing.
>have no string in front of the system literal or publid ID? Can you
>have a public ID that is not preceded by 'PUBLIC' as the model for
>catKeyword implies?) At present I have severe doubts about the validity
>of the catKeyword formal definition.
I don't know how you are reading the production, to fear these
things. The rule is
catKeyword ::= (Char* - (S | SystemLiteral | 'PUBLIC'
| PublicID | catComment))
I.e. a catKeyword consists of some string of characters which is
not white space, not a system literal, not the keyword PUBLIC,
not a PublicID, and not a catComment. Actually, this production
does need revision to ensure that a catKeyword can contain no
space, and that catKeyword doesn't match a public id preceded by
space. Paul's original may be better in that regard, but I had
trouble following it.
>If a catKeyword may be ignored, what is the difference between when it
>is implemented and when it is ignored? We need to explain this to our
What do you mean, what's the difference? When it's implemented, the
desired thing happens. When it's ignored, nothing happens. When the
desired thing is nothing, you can't tell the difference, and so it
doesn't make much difference. Why does telling the difference make any
>Dirty Perl Hacker if we are going to leave such cryptic comments in the
I'm sorry to have been cryptic. But "Implementors, relax. You don't
have to implement the entire catalog spec, just the PUBLIC entry, but
you may implement the entire spec if you like" just doesn't fit with the
rest of the spec in tone or vocabulary. If you have a proposal for a
clearer way to say this than "other entries may be ignored or processed"
the editors will gladly accept suggestions.
-C. M. Sperberg-McQueen