Proposal Announcement - XML DTDs to XML docs

[Marcus Carr]

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.

--
Regards

Marcus Carr                  email:  mrc at allette.com.au
_______________________________________________________________
Allette Systems (Australia)  email:  info at allette.com.au
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:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)