RE: Error on Element Declaration

I agree with Andrew:

In many cases, the XML parsers will have expanded the entity references
during parsing - that will be true in SAX parsers (at least at SAX level
1).  It is not clear to me how parser writers should be treating Entity
References.  Are they used as mere variables in which case, we should
maintain them in nodes so that application writers can change their values
and have the DOM represent the current value, or are they more like a
classical preparser convenience, substituted before building the DOM.

Note: the internals of the SAX parsers I have seen expand the references as
they see them - this is not the way the DOM hierarcy works.

How do people anticipate that application writers will treat Entities?  It
is very important to understand the assumptions being made with the
complexity added for Attribute values.

-MA

At 01:44 PM 5/4/98 -0700, you wrote:
>> -----Original Message-----
>> From: Lauren Wood
>> Subject: RE: Error on Element Declaration
> . . .
>> The idea behind Attributes having children was to have something to keep
the
>> attribute value in. Attribute values can contain entity references
>> in XML, so
>> they can't be simple strings. What else would you suggest?
>
>
>That makes sense.  The only complaint I have is with regard to the burden
that
>places on DOM users who have no need for references to the entities.  My
guess
>is that covers the majority of DOM users.  For example, here is a chunk
out of
>my code.  This is from the March spec, so it is slightly out of date:
>
>  switch( node.getNodeType() ) {
>  case Node.ELEMENT:
>    elem = (Element) node;
>    // Determine if this is a recognized XLink
>    if( (atts = elem.attributes()) != null &&
>        (att  = atts.getAttribute( "xml:link" )) != null &&
>        "simple".equals( ((Text) att.getValue()).getData() ) ) {
>      if( (att  = atts.getAttribute( "href" )) != null ) {
>        href = ((Text) att.getValue()).getData();
>        actuate = show = null;
>          if( (att = atts.getAttribute( "actuate" )) != null )
>            actuate = ((Text) att.getValue()).getData();
>          if( (att = atts.getAttribute( "show" )) != null )
>            show = ((Text) att.getValue()).getData();
>          if( ( actuate == null ||
>                actuate.equals( "user" ) ) &&
>              ( show == null ||
>                show.equals( "replace" ) ) ) {
>            block = new CSSBlock();
>            domRef.append( block );
>            build( (Element) node, block, href );  // Recurse
>          } else if( actuate.equals( "auto" ) ) {
>            // Need to test for embedded images
>          }
>      } else {
>
>You can see that this can get really excessive.
>
>For that purpose, I would like to recommend the following convience method be
>added to either Element or AttributeList:
>
>  wstring getAttributeValue( wstring name );
>
>If the attribute exists, then the the wstring returned would be the value of
>the attribute with all entities expanded.  If it doesn't exist, either
>explicitly or implicitly, then the method should return null.
>
>
>
>Andrew n marshall
>  student - artist - programmer
>     http://www.media-electronica.com/anm-bin/anm
>      "Everyone a mentor, Everyone a pupil"
> 
~-~-~-~-~-~-~-~-~-~-~-~-~-~-WEBEASY-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~
Michael Amster					mamster@webeasy.com
4676 Admiralty Way, Suite 300			Tel: 310.576.0770
Marina Del Rey, CA 90292		       	Fax: 310.576.2011

Received on Monday, 4 May 1998 16:59:41 UTC