Re: Schema for schemas and XML schema DTD

"Fuchs, Matthew" <matthew.fuchs@commerceone.com> writes:

> When Adrian first brought this issue to me I assumed this was an oversight,
> as a Schema for Schemas which can stand independently of a DTD is clearly
> more useful going forward than one which can't (not that the DTD is not
> useful).  The additional effort to do this is minor - just filling in
> default and fixed values.  Then I can truly bootstrap from the Schema for
> Schemas - I read it in as a schema, and then use it to validate itself,
> without reference to anything external.  None of this makes it impossible to
> use the DTD - just makes it optional. 

The DTD _is_ optional.  Nothing about the language defined by the
schema for schemas changes for processors which don't access the
external subset.

> comments below

Ditto.

<snip/>

> But the Schema for Schemas _is_ normative with respect to what is or is not
> a conforming schema document and is itself a schema document.  Therefore it
> should apply to itself - but it cannot do so without access to non-normative
> parts of the spec, because if you were to process the schema for schemas in
> standalone - i.e., without the DTD, it would not express XSDL.

Yes it would.  All the defaults in the DTD just re-interate defaults
already expressed in the prose (or the schema for schemas).  There are 
three ways a conforming processor can be built:

  1) Read schemas minimally (that is, w/o processing external
     subsets), enforce all s-for-s and prose SRC and COS constraints
     in code;
  2) Read schemas maximally (that is, with processing of external
     subset) and/or apply the DTD for schemas as well, enforce all
     non-DTD expressed s-for-s constraints, and all SRC and COS
     constraints in code;
  3) Read schemas ad lib., then apply s-for-s in the approved way,
     then enforce all SRC and COS constraints in code.

I claim which of these three is adopted is completely up to the
implementor, it's clear that they can all give the correct results if
implemented correctly.

The crucial point for the current discussion is that it doesn't
_matter_ where the defaults come from.  The only default values in the 
DTD for schemas are also in the schema for schemas and the prose of
the REC.
  

> Therefore the non-normative DTD is not merely useful, it is
> _required_.  Something normative should not _require_ the presence
> of something else which is not normative.  _Allowing_ the presence
> of something non-normative is a different issue.

I hope I've shown above that it's _not_ required.  E.g.

  <element name="schema" id="schema"> [quoted from the s-for-s]

has abstract='false' by default, _not_ (just) because such a default is
in the DTD for schemas, but because it's in the s-for-s, and in the
prose of the REC, that that's the default.


> As you well know, XML 1.0 specifies two levels of conformance - well-formed
> and validating.  The Schema for schemas currently requires a _validating_
> processor.

Not so.

> Making the changes Adrian suggests - just putting in default and
> fixed values - would lower the bar to implementation to a well-formed
> processor in standalone mode.

But you _can't_ do that, or such processors won't work correctly with
other schemas -- the defaulting _must_ be implemented somewhere!

> Requiring a DTD breaks all of these principles for the Schema for Schemas:
> 1) the language is not expressed in instance syntax, but requires a DTD

False.

> 2) it is not self-describing as written - it requires a DTD, which is not
> part of XSDL.

False.

> 3) not useable by processors which don't want to validate

False.

> 4) is not straighforwardly useable, as it requires a separate document (the
> DTD)

False.

> 5) ditto

False.

ht
-- 
  Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
          W3C Fellow 1999--2001, part-time member of W3C Team
     2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
	    Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk
		     URL: http://www.ltg.ed.ac.uk/~ht/

Received on Friday, 3 November 2000 03:25:41 UTC