[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: 25 Feb Structures Comments

  • From: ht@c... (Henry S. Thompson)
  • To: "Arnold, Curt" <Curt.Arnold@h...>
  • Date: 02 Mar 2000 18:24:25 +0000

minoccur .net
"Arnold, Curt" <Curt.Arnold@h...> 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@c...
		     URL: http://www.ltg.ed.ac.uk/~ht/

***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@x...&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/threads.html
***************************************************************************

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.