Re: 25 Feb Structures Comments

"Arnold, Curt" <Curt.Arnold@hyprotech.com> writes:

> Section 2.2: Model groups is classified twice in the
> definition of schema component, once as a secondary
> component and once as a help component.

Model group definitions (primary) are not the same as model groups
(secondary).  This is not transparent nomenclature, I agrfee.

> Section 2.2.1.3: I can't get my mind around the
> "Each is (sic) complex type definition is..." part.
> Aren't some complex type definitions a extension
> of the ur-type?

Since the complex ur-type allows absolutely anything, all other types
can only be restrictions of it.

> Section 2.2.2.2: Should equiv class names be QName's?

They are -- see 4.4.2  --- what makes you think they aren't?

> Section 4.1: It seems unnecessary and complicating to
> allow multiple annotation elements within the schema
> element.  It would tend to be interpreted as pertaining
> to the next child element vs being a annotation of the
> schema as a whole.

It seemed even more unnecessary and irritating to us to constrain
top-level annotation to any particular place in the schema.  If we did 
that, people would just start using comments again :-(

> It would also seem that allowing an RDF
> element for metadata would be appropriate.

That's what the appinfo child of documentation is for.

> Section 4.3.1: In the long run...
> 
> Actually, the schema components do appear to have id attributes
> of type ID which allow referencing schema components now.

True.  Prose is stale.

> Section 4.4.3:
> 
> minBound and maxBound appear in addition to minExclusive et al
> in the content of complex type.

Stylesheet bug, sorry.

> anyAttribute does not allow annotation.  I think it would be
> useful to include descriptions of what alien attributes
> might be anticipated.

Bug, thanks.

> Section 4.4.1:
> 
> I assume the fairly complicated section on attribute 
> groups from other namespaces is to support validation
> of attributes like xlink:href by defining a attribute
> group in the xlink schema and namespace and including
> an attribute group reference in the element's definition?
> Maybe an example would be useful.
> would be useful.  Doesn't appear to give you any
> mechanism to restrict the values, but 

This facility is under review, thanks.

> Section 4.4.7: processContents
> 
> I assume that one of these modes is appropriate for XSLT
> literal result elements (ideally that the element content
> model is not validated, attribute presence is validated,
> attribute typing is validated if there is not a "{ }" in
> the attribute).

That's a little _too_ specialised for this version . . . 

> any does not allow annotations either.  Again it would be
> useful to include descriptions of what alien elements
> might be anticipated.

Noted.

> I assume that you could support different processContent
> setting for different namespaces by using <any> elements
> in a <sequence> such as:
> 
> <sequence minOccur="0" maxOccur="*">
>     <!--  not the write namespace but you get the idea -->
>     <any minOccur="0" namespace="http://www.w3.org/XSLT" 
>         processContents="strict"/>
>     <any minOccur="0" namespace="##any" processContents="lax"/>
> </sequence>

Nope, that's an ambiguous model, since ##any and .../XSLT overlap.
Too sophisticated for this version in my opinion.

> If not, how do you do it.

In the XSLT schema, you user ##other above instead of ##any, and then
the two don't overlap.

In other cases, 'lax' is close to what you want -- will validate the
XSLT bits, and skip the user bits if there's no schema for them.

> Section 5.3.2: "schemaLocation" attributes can occur
> on any element participating... validation root.
> 
> Unless I'm reading this wrong (in which case better
> prose is in order), this appears to make event-based
> validation difficult if not impossible since you
> may not know the schema location until much of the
> document has been processed.

That's right -- if you try to laxly validate in a streaming fashion,
you may find schemaLocation information later than you would like and
have to either bail or start over.  We didn't see any acceptable
alternative:  you wouoldn't want the results to be different for batch 
and streaming processing, would you?

> If would seem reasonable that "schemaLocation"
> indicates the schema to be used for the scope 
> of the containing element.  That would also
> allow for different schemas for the same
> namespace (for example, a document that 
> contains fragments from files that were
> written with different versions (and hence
> different schemas) of one application (same
> namespace)

We were not prepared to go there for v.1

> Appendix A: Schema for Schemas
> 
> annotation, documentation and appinfo do not 
> appear in structures schema (they are in
> the datatypes schema), though they are in
> the structures text.

They _are_ in the structures schema, just not in the structures.xsd
schema document.

> The <sic> element appears though not discussed
> in the body of the document.

Stale -- should be removed, sorry.

> Note: Derivation by restriction of complex types
> is not discussed in detail in the document though
> there is substantial potential for ambiguity.
> I'll try to outline something in a separate message.

This gap should have been better signalled, we ran out of time to get 
a recent change in this fully documented.

====
Thanks for useful feedback.

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 Thursday, 2 March 2000 13:24:41 UTC