Re: Parameter entities vs. GI name groups

> 
> The ERB, in its meeting yesterday, discussed the issue of parameter
> entities in XML.  We are *strongly* leaning towards voting to remove
> parameter entities entirely *from V1.0* as long as GI name groups are
> reinstated in ELEMENT and ATTLIST declarations:

I certainly would *not* like it if parameter entities are removed.  I don't 
see that we can properly solve the re-use and namespace issue in the time
we have.  This should certainly be a goal but not for 1.0.

> <!ELEMENT (a|b|c) ...>
> <!ATTLIST (x|y|z) ...>

I have moved away from using name groups myself in SGML for element 
declarations.  I just find that I have to break up the element declaration at 
some point later.  

It is also much easier to comment the DTD if I have a separate element
declaration.

> We plan to vote on this at next Wednesday's meeting; your input is welcome.
> 
> The reasons to prefer GI name groups:
> 
> o Many of the uses of parameter entities that new DTD writers and simple 
>   DTDs are likely to want can be replaced by GI name groups: synchronizing 
>   the content models or attribute lists of elements

I not certain that this is a validated statement.  Where is the historical
precedence for this?  For people who have taught DTD writing, what is your
opinion?

In my experience, I have found that people have a hard time understanding
managing DTDs with common declarations--either name groups or parameter
entities.  Hence, I don't see how inclusion or exclusion of name groups
or parameter entities are going to solve a philosophical problem. 

In consequence, I don't see how inclusion of name groups and removal
of parameter entities do anything but hurt the advanced user.

How about add name groups and keep parameter entities?

> o GI name groups add extremely little complexity to XML processors

Agreed.

> o Now that we have multiple ATTLISTs, GI name groups have quite a bit more
>   power than they used to (e.g., you can add a set of attributes to "all
>   the list elements," and then add a unique attribute to only one of the
>   elements)

Agreed.  This is one place where I would use name groups quite often.

> o GI name groups give us the syntax (if not the semantics) to do a kind of
>   element subclassing, where all the elements in a "class" have the same
>   characteristics

I not certain that historical precedence dictates that this would be common.
How often do we say that something is the same structure by a different name?  
It is probably far more often that we can say something is similar--either being
more flexible and structured or more restrictive.  This is where we tread on
weak ground in that we want/need element type sub-classing and sub-typing--which
is a far more complex topic in that element types do not contain unordered 
members.  Subclassing an element type requires identifying how to modify a
content model and affect the order which is not a trivial task. 

> One consequence:
> 
> o Existing DTDs and any new complex DTDs that need parameter entities would
>   have to be transformed to resolve parameter entities before XML delivery
>   (note that several existing tools, such as NormDTD, do this)

I'm certainly not for this.  Now I need a DTD management system for XML.  The
technology hurdle was just raised for any but a trivial environment.  Since I
rarely get a chance to work in trivial environments, that means the technology
hurdle was raised for every XML application I might develop.

I will admit, I'm not real happy with parameter entities.  I'm also not real
happy with removing them until we have some *better* to replace them.

...just my two cents.

==============================================================================
R. Alexander Milowski     http://www.copsol.com/   alex@copsol.com
Copernican Solutions Incorporated                  (612) 379 - 3608

Received on Friday, 20 June 1997 10:27:06 UTC