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


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: XSchema Spec, Sections 2.0 and 2.1 (Draft 1)

[ Lists Home | Date Index | Thread Index ]
  • From: "Matthew Gertner" <matthew@praxis.cz>
  • To: "XML Dev" <xml-dev@ic.ac.uk>
  • Date: Tue, 9 Jun 1998 11:09:31 +0200

>By keeping entities _out_ of XSchema we can:
>a) take advantage of one of the things XML currently does reasonably well
>b) leave room for all kinds of entity madness in a _future_ standard
>c) ensure interoperability with well-formed XML documents
>d) make XSchema _much_ less work to implement
>Sound good?

Chalk up one vote for this. I just can get over the feeling that including a
mechanism for entity declarations in XSchema would be a step in the wrong
direction. Okay, this has a lot to do with the fact that I never liked the
way entities are managed in the first place. It is extremely confusing to
someone learning XML that referencing some external binary data and
transcluding external text use the same mechanism. On top of this, an entity
reference syntax is simply too terse. They is no way to document or
parameterize the use of an entity reference (without resorting to comments),
which is why it was necessary to invent XLink in the first place.

As far as parameter entities are concerned, I sincerely hope that XSchema
will evolve a way to handle content model reuse cleanly in the future. A
combination of what is essentially text replacement combined with
overloading of entire attribute lists and content model declarations is not
going to cut it in the mass market. There seems to be general agreement
about this.

For other entity types (internal, external parsed and unparsed), using XLink
instead of entity references seems to have overwhelming advantages. It is
more flexible (e.g. enabling multiple targets), cleaner (e.g. enabling
specification of link and content roles) and doesn't require the use of an
additional low-level syntactic construct. As far as text transclusion is
concerned: isn't this the purpose of the "embed" value for the "show"

It would probably be legitimite to ask what this has to do with XSchema, but
this just drives the point home. Text-replacement mechanisms have nothing to
do with defining a class of document and certainly nothing to do with
defining appropriate mechanism for schema reuse. Both of these issues would
be fascinating areas for future discussion; IMO they should be kept separate
from the initial XSchema spec.



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


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

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