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

Re: XSchema Spec - Content Model Declarations (Section 2.3), Draft 4

• From: rbourret@d... (Ron Bourret)
• To: xml-dev@i..., cowan@l...
• Date: Mon, 13 Jul 1998 14:14:37 +0200

John Cowan wrote:

> Ron Bourret wrote:
> 
> > One can imagine an XSchema where the top-level element declarations 
themselves
> > are relatively useless but exist so that an XLink can refer to their content
> > models.  This is a bit hacky, but it's the only way I can see to duplicate 
the
> > horiz.model and vert.model entities in John Cowan's Itsy B
> > Bitsy Teeny Weeny Simple Hypertext DTD.
> 
> Very kludgy indeed.
> 
> I have one new proposal and one old one.  I'm thinking that several more
> elements should be allowed at top level, namely AttDef, Choice, Sequence,
> Mixed, NotationType, and EnumerationType.  These would then exist
> as free-floating resources which could be referred to by idrefs
> elsewhere.
> 
> The old proposal is for an AttGroup element, with a content model
> of (Doc?, AttDef+), and available at top level and also within an Element
> model.  This would allow multiple attributes to be treated as a
> single thing for either documentation or reference.

I think what both of these suggestions and the discussion about root elements 
describe is the tension between two overlapping aims of XSchema.

The first aim is to provide what I will call an instance syntax -- that is, the 
syntax of an XML document that people should follow exactly.  The second aim is 
to provide a bag of definitions that can be used elsewhere.  Note that while 
XSchemas in the first case can, with a bit of work, be reused as the second 
case, the opposite is unlikely to be true.

Our current syntax satisfies the first aim.  John's first suggestion satisfies 
the second aim.  The XSchema subelement is a mechanism for grouping definitions: 
a group of attributes (negates the need for AttGroup), a group of element 
declarations, a complete content model, etc.  To reference such a group, all you 
need is the XPointer xschema-subelement-id.child(all).

I therefore think we should do the following:

1) Add the following sentence to the end of the first paragraph in section 2.1 
after the syntax:

"... The XSC:XSchema element may also contain other XSC:XSchema elements nested 
inside of it. ****This allows one XSchema document to contain other XSchema 
documents.  It also serves as a way to group XSchema elements for inclusion in 
other XSchema documents.****"

2) As John suggests, expand the legal elements beneath an XSchema element.  In   
 particular, add AttDef, Choice, Sequence, Mixed, and Ref to the XSchema 
element.  (NotationType and EnumerationType no longer exist.  I have added Ref 
to John's list.)

-- Ron Bourret

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)

• Follow-Ups:
  • Re: XSchema Spec - Content Model Declarations (Section 2.3), Draft 4
    • From: John Cowan <cowan@l...>

• Prev by Date: Re: XSchema Spec - Attribute Declarations (Section 2.4), Draft 4
• Next by Date: Re: XSchema Spec - Extensions (Section 2.6), Draft 2
• Previous by thread: Re: XSchema Spec - Content Model Declarations (Section 2.3), Draft 4
• Next by thread: Re: XSchema Spec - Content Model Declarations (Section 2.3), Draft 4
• Index(es):
  • Date
  • Thread