Re: SPEC - isA

Len Wanger ([email protected])
Thu, 18 May 1995 15:55:14 +0100


>> To be easy to parse, we'd probably then want to say that isA needed to
>come
>> before any other fields. A parser would have trouble with:
>>
>> ExtendedMaterial { fields [ MFString isA ]
>> diffuseColor .8 .54 .1
>> isA "Material"
>> }
>>
>
>I still think it is tricky to parse. This is especially true if you give
>more than one string to isA. How do I choose? The first one I
>understand? The best match with the given fields? The easiest way to
>handle isA is to read in the node as unknown, then go back and see if
>there's an isA field. If so, match up the field and types and pick an
>existing node based on that. This would require a fully specified fields
>field.

I'm confused here. I thought the whole reason for the "fields" field was to
know what type the field was so you can skip over it. When you get to an
extension node you either know its type or not. If you know its type then
you also know its fields and you read the node in. If you don't know about
the node type you read in the next field tag and either:

1) If its "fields", use the fields value to skip over the data without
storing them (i.e. blow off the node).

or 2) If its "isA" you create a node of the type specified by the isA and
use the fields values to help skip over the fields you don't recognize.

Seems pretty simple and its done in one pass.

>I agree with Gavin that this will not be a big bandwidth drain. Gzip can
>compress repeating field names really well. And you needn't specify an
>existing node fully. This will work:
>
> Refraction {
> fields [ MFColor diffuseColor, MFFloat refractionIndex ]
> diffuseColor 1 1 0
> refractionIndex 0.5
> isA "Material"
> }
>
>This should create a material node, set the diffuseColor field to the
>given value and leave the others at their default.

Its not about being a bandwidth drain as much as making it that much more
difficult for the vrml author. Why burden the author with typing in all
that crud if its implicit information from the node type.

Len Wanger

Interactive Simulations, Inc. Email: [email protected]
5330 Carroll Canyon Rd, Suite #203 Phone: (619) 658-9783
San Diego, CA 92121 FAX: (619) 658-9463
http://www.intsim.com/~isigen