OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   25 Feb Structures Comments

[ Lists Home | Date Index | Thread Index ]
  • From: "Arnold, Curt" <Curt.Arnold@hyprotech.com>
  • To: "'www-xml-schema-comments@w3.org'" <www-xml-schema-comments@w3.org>, "'xml-dev@xml.org'" <xml-dev@xml.org>
  • Date: Tue, 29 Feb 2000 08:04:44 -0700

Here are some comments on XML Schema structures based
a quick initial read:

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.

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?

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

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 would also seem that allowing an RDF
element for metadata would be appropriate.  Something like

(rdf:rdf?,annotation?,(include|import)*,(simpleType|complexType|
element|group|notation)+)

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.

Section 4.4.3:

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

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

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 

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).

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

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>

If not, how do you do it.


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.

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)

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.

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


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 is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/threads.html
***************************************************************************




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS