[X3D-Public] containerField is should or must ? large attributes; compression

[Joe D Williams]

> mix poorly with conventional XML parser design

I think we found problems with old html parser design that defaulted 
different treatments between attributes and element content. 
Specifically,m the attribute value was saved diertly to memory while 
the element content was passed on into a file. There is no XML 
requirement for max length of either attribute value or element 
content length that I have seen. At that time, element content could 
not be an arbitrary type. Given that attributes are meant to be final 
data,there is no problem with the way we did it originally. The 
totally correct signature as far as I am concerned is that either way 
fo doing it should be to allow either:

... point="list of data points"

or

<point>list of data points ...</point>

so if we use a wrapper tag to send the data as element content, we 
should use the same element name as is now specced for the attribute 
value. I still think the schema might be rigged to allow either.

Joe



----- Original Message ----- 
From: "Don Brutzman" <brutzman at nps.edu>
To: <x3d-public at web3d.org>
Sent: Monday, August 09, 2010 1:52 PM
Subject: Re: [X3D-Public] containerField is should or must ? large 
attributes; compression


> On 8/8/2010 9:49 PM, Braden McDaniel wrote:
>> On Sun, 2010-08-08 at 18:24 -0700, Don Brutzman wrote:
>>  > [summary: lookouts have sighted large icebergs ahead, port and
>> starboard...]
>>  >[...]
>>  > > >> There's no question that containerField is made necessary 
>> by other
>>  > > >> aspects of the XML encoding. Unfortunately, time has shown 
>> that
>> those
>>  > > >> aspects are themselves poor design choices.
>>  >
>>  > certainly our knowledge and skills have grown over time, which 
>> is good.
>>  > however not sure what "poor design choices" means.
>>
>> It means that, considering a major motivation for XML is to make 
>> parser
>> design more simple, uniform, and straightforward, design decisions 
>> that
>> mix poorly with conventional XML parser design or that introduce a 
>> level
>> of complexity that is hard to justify (based either on the 
>> functionality
>> they enable or the complexity of alternative approaches) are bad 
>> ones.
>
> thanks for the clarification.
>
> not sure there are any major alternative designs, regardless of 
> whether
> the resulting design is finest possible (or maybe least-worst) 
> approach
> that adequately reconciles both XML and X3D architectural 
> principles.
> deployment is a major challenge, we can't just jettison existing 
> work
> and existing content.
>
> all the best, Don
> -- 
> Don Brutzman  Naval Postgraduate School, Code USW/Br 
> brutzman at nps.edu
> Watkins 270   MOVES Institute, Monterey CA 93943-5000 USA 
> +1.831.656.2149
> X3D, virtual worlds, underwater robots 
> http://faculty.nps.edu/brutzman
>
>
> _______________________________________________
> X3D-Public mailing list
> X3D-Public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org