RE: General issues, how to replace entities in DTDs using XInclud e.

The Core WG completed consideration of your request today, and decided
not to add this functionality to XInclude 1.0.  The sentiment was that
this is an interesting line of investigation, but would require a
dramatic expansion of the functionality of XInclude, which is in
conflict with our goals of providing a minimal specification for 1.0.
It also might be possible that an XML representation of entities and
entity references should be provided as a separate specification, as the
goals are somewhat different than those stated for XInclude.

I'll also note that XInclude is NOT intended as a full replacement for
entities, which is a perception that we will have to combat more
effectively.  It is a modularity mechanism designed to complement
entities, and overcome some of the problems encountered by users of
external entities for modularity purposes.

- Jonathan Marsh

> -----Original Message-----
> From: Jonathan Marsh
> Sent: Wednesday, March 07, 2001 9:45 AM
> To: 'Ray Whitmer'; www-xml-xinclude-comments@w3.org
> Subject: RE: General issues, how to replace entities in DTDs using
XInclud
> e.
> 
> Thanks for the comments.  I will add them to our issues list for
> discussion.
> 
> I especially look forward to the discussion of redundancy with
entities.
> In
> general we have tried to make XInclude compliment entities rather than
> replace them, in the interest of reducing redundancy (under the
assumption
> that XML 1.0 entities will never go away).  Your suggestion for full
> rendundancy in order to begin migrating away from entities shows that
> there
> are two opposing solutions for dealing with the redundancy issue, and
now
> is
> an opportune time to double-check that we're really going down the
right
> path.
> 
> > -----Original Message-----
> > From: Ray Whitmer [mailto:rayw@netscape.com]
> > Sent: Tuesday, March 06, 2001 1:50 PM
> > To: www-xml-xinclude-comments@w3.org
> > Subject: General issues, how to replace entities in DTDs
> > using XInclude.
> >
> >
> > I have been a heavy user of entities for a long time in SGML
> > and then XML.
> > I am quite reluctant to give up entities, because they fit so many
> > different
> > use cases.  As such, I find XInclude redundant until it can replace
> > entities.
> >
> > While XInclude does not claim to replace all entities, replacement
> > is the only basis upon which I can accept yet another way of
including
> > external stuff -- I feel we must be in a position to retire
> > one thing  for
> > domains where we use the new thing.
> >
> > Here is an informal description of additions to XInclude
> > which could solve
> > these problems while remaining as an infoset transform.  This would
> > augment, rather than replacing, the existing XInclude specification,
> > which is
> > useful as it exists for referencing external entities and as
> > base principles
> > for these proposed extensions.
> >
> > 1.  The ability to have local entity declarations.
> >
> > I suggest 2 new element types called "xinclude:entity" and
> > "xinclude:eref"
> > to model entities as an infoset transform, which can be
> > intermingled with
> > other elements and other xinclude elements:
> >
> > For example:
> >
> > ...
> > <!ENTITY bar "value">
> > ...
> > <fooroot>
> > ...
> >           &bar;
> > ...
> > </fooroot>
> >
> > Would become:
> >
> > <fooroot xmlns:xi="http://www.w3.org/1999/XML/xinclude">
> >   <xi:entity name="bar">value</xi:entity>
> > ...
> >           <xi:eref name="bar"/>
> > ...
> > </fooroot>
> >
> > Included infosets may not contain unresolved erefs -- each infoset
> > must be independently resolved.  But included infosets may include
> > first-level entities which remain active to the end of the
> > scope where it
> > is included permitting sharing of common entities between infosets.
> >
> > This allows entities to be scoped, making it easy to nest XML
> > documents
> > with entities inside of other XML documents.
> >
> > 2.  Ability to reference inclusions and entities from
> > attribute values.
> > This
> > is a common use case for SGML and XML.  It was probably left out of
> > XInclude because local declarations were left out.
> >
> > I suggest a new element type called "xinclude:attr" used to model
> > unspecified attributes as child elements at the start of the
> > child list
> > so that they may contain inclusions and erefs.
> >
> > For example:
> >
> > ...
> > <!ENTITY name "Ray Whitmer">
> > ...
> > <fooroot>
> > ...
> >          <use1 title="My name is &name;"/>
> > ...
> > </fooroot>
> >
> > Would become:
> >
> > <fooroot xmlns:xi="http://www.w3.org/1999/XML/xinclude">
> >   <xi:entity name="name">Ray Whitmer</xi:entity>
> > ...
> >          <use1><xi:attr name="title">My name is <xi:eref
> > name="name"/></xi:attr></use1>
> > ...
> > </fooroot>
> >
> > 3.  Compatibility with legacy syntax.  There are lots of old
> > documents, and
> > the existing syntax for general entity references, used
> > throughout XHTML,
> > for example, is far more convenient than using xinclude elements.
> >
> > XInclude-aware parsers should make the following transformations
> > automatically:
> >
> > a.  Create entity elements inside root element instead of
> > internal subset
> > general entity declarations (using nested xinclude:include element
> > for external entities).
> >
> > b.  Transform entity references to the equivalent XInclude elements,
> > using alternative attribute syntax where they occur in
> > attribute values.
> >
> > c.  Bootstrapping the document type could occur by
> > automatically adding
> > xincludes to the top of the root element based upon document
> > type.  The
> > parser could refer to a document to map doctypes to appropriate
> > bootstrapping xinclude declarations.
> >
> > 4.  Compatibility with DOM.  This proposal would solve all of
> > the problems
> > DOM has today with entity references.  It would permit
> > nearly-transparent
> > use of the new XInclude transforms instead of entities, or the DOM
WG
> > could choose to support them in some new way.  Entity references
would
> > need to update their read-only child content whenever a new entity
> > declaration becomes visible in the scope, which is a new problem
that
> > seems quite solvable.  xinclude:include's might need some
alternative
> > form of representation.
> >
> > This is my take on XInclude.  I am not (yet) speaking for my
> > company or
> > any other working group.  I realize that my proposed changes
> > are probably
> > considered out of scope.  People keep trying to tell me that
> > we don't need
> > DTDs any longer with XSchema and XInclude.  I would like for
> > this to be
> > true.
> >
> > There are corner cases which remain unsolved, but it solves
> > enough of the
> > domain for me to consider outlawing the corner cases and it
> > permits me to
> > get excited about a new world that uses XInclude/Xschema
> > instead of DTDs.
> >
> > I can provide more use cases if you are interested.
> >
> > Ray Whitmer
> > rayw@netscape.com
> >
> >

Received on Wednesday, 11 April 2001 12:32:40 UTC