Re: USES Notations (was part of Update on namespaces)

> From: Martin Bryan <mtbryan@sgml.u-net.com>
 
> You can only attach link
> notation processors to valid link elements. You can only attach CALS tables
> notation processors to elements that conform to the CALS table model

No, because I might have a document with no CALS tables that I want to edit.
And I might have no explicit DTD but still want to enforce it/note it as an additional 
requirement.

> The XML-lang notation applies to the SGML declaration as well! Is it enough
> to reference it as part of the DOCTYPE?

The additional requirements do not necessarily enforce anything: they primarily note
the additional requirements exist for the document that are not dealt with by all SGML's
levers, knobs and switches. Software could also use this information to track down a
processor (or check the correct processor is in use) that implements some or all of the
additional requirements, depending on what is at hand.

> > How do architectural forms
> >let me say "actual columns must agree with the column number attribute in
> the table
> >element"
> 
> That must be a text based-semantic that is indirectly associated with the
> table element as that is the container for the columns. (This type of use of
> SEEALSO as referenced in TC2 is invalid and needs challenging! Its not SGML
> declaration dependent or generally applicable to all associated doctypes.)

No
 
> > or "you cannot use  RCDATA declared content types in your element type
> >declarations" or "you cannot use TEMP marked sections"
> 
> These constraints must be specified before the DOCTYPE is processed (if it
> is). The safest place to specify this is in the SGML Declaration, which in
> XML's case is fixed, and is automatically presumed, otherwise the xml-lang
> stuff has to go in every Doctype statement.

No, my example was used XML just because it is familiar, not because you'd need
to do it, or always want to do it.  Once you've extablished that document is XML 
by the MIME type or PI header, then requirements additional to XML & SGML could
be given using this mechanism as desired.

> > or "you can only be using the
> >XML SGML declaration"?
> 
> This one is interesting. Can you by pointing to the XML spec from an SGML
> declaration force that declaration to conform to the rules about SGML
> declarations specified in that spec? I'm not sure whether this is valid.

For post-parse validation, sure. 

> >The additional requirement must be NOTATION
> 
> I see this is enshrined in the draft text for TC2, but want to know why -
> what's wrong with pointing to a meta-DTD?

Because an additional requirement is to set syntactical and (maybe) semantical 
rules that SGML and architectural forms do not cover.   I don't see any overlap
between AF and Additional Requirements: they cover completely different areas. 
I don't know if SEEALSO should allow AFs as well as Additional Requirements,
I don't think so, because the SEEALSO is explicitly a way to rope in extra-SGML
constraints which effect extra-SGML validation, perhaps just by humans.

An example of an additional requirement is this:

"In
	<!ATTLIST cat
		colour (black|white|tabby|other) #REQUIRED
		other-colour CDATA #IMPLIED>
if you specify 'colour=other', you must also specify other-colour attribute."

This Additional requirement would be put into a document, given a public identifier.
A processor to check this could also be developed, and some software might plug
it in an use it for validation or as a generate-time constraint or whatever: the important
thing is it is a way to make sure that a DTD can be more completely documented, and that
the documentation is bound to the DOCTYPE declaration sufficiently tightly that a
computer could make use of it too: by selecting a notation processor registered in
the catalog for that public identifier.

Rick Jelliffe

Received on Friday, 13 June 1997 03:25:30 UTC