Lists Home |
Date Index |
- From: Marcus Carr <email@example.com>
- To: "Xml-Dev (E-mail)" <firstname.lastname@example.org>
- Date: Thu, 21 May 1998 12:19:26 +1000
Simon St.Laurent wrote:
> > What about issues such as redefining a parameter entity in the
> > external subset? Or multiple identically named parameter
> > entities within the DTD?
> These could both be defined by specifying the behavior for the
> DTD-as-document, just as they are now for DTDs. I see no difficulty here.
It seems that you are proposing ascribing characteristics to an entire class of
XML documents, that is, when you encounter a particular element you ignore it
based on the existence of a previous element's characteristics. That's essentially
the behaviour of parameter entities, but is a semantic not automatically imposed
on other XML documents. In my opinion, this difference is significant grounds for
not making DTDs XML.
> > Sticking with parameter entities, what if the same entities
> > behaved as a content model and an attribute name?
> > How and why would you make the distinction with the proposed
> > syntax?
> How and why would you make the distinction with the current syntax? Why would
> this be so difficult to do in a document rather than the current syntax?
You wouldn't currently make the distinction, but you don't need to. In your
example you indicated that a the parameter entity resolved to a content model
(sorry, I'm working from memory). Assuming that a parameter entity is just a
straight text replacement, you probably shouldn't make any determination about
it's use at the time of declaration, though this may just be a syntactic issue.
> Parameter entities are admittedly my least favorite part of XML, a necessary
> evil and a powerful tool. There may well be limits on how well they can map
> to this model - but is that a significantly worse limitation than the
> abolition of the & content model? I think the manageability you'd gain with
> this representation of XML DTDs would more than compensate for any loss
> incurred by the enforced simplification of parameter entities.
Having done some work with a Docbook derivative lately, I would argue that yes,
messing with parameter entities could be more damaging for less gain than the
abolition of the & model. I suppose I come from the camp that prefers no change,
but I don't really find manageability a major issue - if I want a different view
of the DTD, I could always convert it to HTML or use any number of applications to
present it nicely. If you mean to extend the information stored in a DTD, I would
also prefer to see this done within the existing framework as much as is feasible.
> To a certain extent, this is certainly true. However, I think there's a
> strong case to be made for using a single syntax - see the advantages listed
> in the Rationale.
I did read it, but I accidently deleted the mail before recording the URL - could
you send it to me again? Thanks.
Marcus Carr email: email@example.com
Allette Systems (Australia) email: firstname.lastname@example.org
Level 10, 91 York Street www: http://www.allette.com.au
Sydney 2000 NSW Australia phone: +61 2 9262 4777
fax: +61 2 9262 4774
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)