[x3d-public] x3d extensions through Metadata; ExternProtoDeclare also possible
Andreas Plesch
andreasplesch at gmail.com
Sun Jul 9 21:30:25 PDT 2023
I put together an experimental x3dom build which can use Metadata as
an extension mechanism as outlined below. The x3dom editor at
https://andreasplesch.github.io/Library/Viewer/index.html
uses the experimental build.
Here is an example:
https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/415d151abee114858c79c20c8c4b49e0/raw/fea949cd6600714b915902b9486152f7c63fb385/MetadataExtensions.x3d
The implementation strategy is to modify the parent node dom when
encountering extension metadata while parsing by augmenting attributes
for extension fields or children nodes for extension node fields.
Modifying the parent dom in turn triggers the regular mutation
observer which updates the x3d node represented by the parent dom.
This seems to work but is not fully tested sofar and may not work for
initialize only extension fields since they cannot be updated.
An interesting side effect is that this mechanism would also work for
standard fields and nodes. Since the metadata nodes can be reUSEd, it
becomes possible to reUSE non-node fields which is normally not
possible. For example, metadata could DEFine '1 0 0' for a
diffuseColor field as RED, and then reUSE RED for diffuseColor but
have variable transparency for other materials.
The intention is to facilitate backwards compatible node development
work outside of Prototypes. Actual use of non-standard fields in
applications would probably prefer regular xml attributes and
elements.
Note that metadata to the extension metadata could be used for
documentation, versioning and such, if preferred over xml comments.
Finally, note that although the mechanism is for the xml encoding, it
may be used also for other encodings if the MetadataString value for
node extensions contains the node in another encoding such as x3dv or
json ( with the appropriate escaping ).
Suggestions or any feedback always welcome,
Andreas
On Fri, Jul 7, 2023 at 3:05 PM Andreas Plesch <andreasplesch at gmail.com> wrote:
>
> From an implementation perspective, and also validation perspective,
> focusing on just the xml encoding would keep using Metadata for
> extensions really simple.
>
> For non-node fields ("sortKey" or "interpolator") special Metadata
> could use MetadataString with name as the field name and value[0] as
> the string of the corresponding xml attribute:
>
> <Appearance DEF='app'>
> <MetadataString reference="X3DFieldExtension" name="sortKey" value='
> "2.0" ' containerField="metadata" />
>
> For node fields ("depthMode") name would also be the name of field and
> value[0] the xml encoded node:
> <Appearance>
> <MetadataString DEF="specialMetaString" reference="X3DNodeExtension"
> name="depthMode" value=' "< DepthMode DEF=\"noZ\" readonly=\"true\"
> /> " ' containerField="metadata"/>
>
> I think this is all that is needed, and is pretty readable.
>
> A browser could then just use the Metadata to augment the xml encoded
> file with these extensions. Strictly speaking, a browser with
> implemented extensions would be able to know the type of field based
> on its name and not require a distinction between non-node and node
> fields but providing a hint would be very helpful and serve as a bit
> of consistency check. The encoding of xml inside a MFString is a bit
> tricky but perhaps not too cumbersome. Similarly, putting an MFString
> inside MFString[0] requires escaping but should be possible ( value='
> " \' \"first\" \"second\" \' " ' might work) .
>
> Routes would target directly the def name ("noZ"), or field name
> (app.sortKey) of an extension node. Routes to the Metadata
> ("specialMetaString") would not be forwarded automatically to the
> extension field.
>
> The reference value could refer to X3D4.x for extensions targeted at
> the standard ("X3D4.1_Extension"), or to other, browser specific
> classes ("AR_Extension").
>
> I would be interested to work on an experimental x3dom implementation
> of this simple extension MetadataString based mechanism for testing if
> there is interest.
>
> -Andreas
>
>
>
>
>
> On Tue, Jul 4, 2023 at 12:40 PM Brutzman, Donald (Don) (CIV)
> <brutzman at nps.edu> wrote:
> >
> > Yes interesting. Good to know where the horizon of effectiveness lies (rather than tumbling over outer boundaries).
> >
> >
> >
> > In general, I don’t think renaming core nodes is a good practice. Too prone to misinterpretation and misunderstanding, too difficult to validate, fails mysteriously when out of context. Key approach in XML and Semantic Web is use of namespaces, explicitly defining context instead of permitting overloaded ambiguity.
> >
> >
> >
> > Our team’s heuristic for naming conventions comes from Jeff Weekley,
> >
> >
> >
> > X3D Scene Authoring Hints: Naming Conventions
> > (Ironic) Success Metric: when is a name successful?
> > Answer: when no one has to discuss that name any more, it is simply understood.
> > https://www.web3d.org/x3d/content/examples/X3dSceneAuthoringHints.html#NamingConventions
> >
> >
> >
> > Even more fundamentally:
> >
> >
> >
> > Wikipedia, David Wheeler
> > https://en.wikipedia.org/wiki/David_Wheeler_(computer_scientist)#Quotes
> > Wheeler is often quoted as saying "All problems in computer science can be solved by another level of indirection."[26] or "All problems in computer science can be solved by another level of indirection, except for the problem of too many layers of indirection."[27] This has been called the fundamental theorem of software engineering.
> >
> >
> >
> > 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 graphics, virtual worlds, navy robotics https://faculty.nps.edu/brutzman
> >
> >
> >
> > -----Original Message-----
> > From: Andreas Plesch <andreasplesch at gmail.com>
> > Sent: Monday, July 3, 2023 7:47 PM
> > To: Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
> > Cc: GPU Group <gpugroup at gmail.com>; X3D Graphics public mailing list <x3d-public at web3d.org>
> > Subject: Re: [x3d-public] x3d extensions through Metadata; ExternProtoDeclare also possible
> >
> >
> >
> >
> >
> > Hi Don,
> >
> >
> >
> > This method works if adding a new extension field to an existing node also means defining a new node. In the example 'MaterialModulator' is the new name for what was the Material node. However, the task is to add a new field to an existing node without changing its name. This is the difference between an extension adding a field and an extension defining a new node.
> >
> >
> >
> > Using ProtoDeclare would work for this if it would be allowed to reuse an existing node name, here Material. But this is likely not allowed since it could lead probably to cyclic redefinitions.
> >
> >
> >
> > An idea may be to actually require use of an existing node name for a special extension ExternProtoDeclare statement. Extension ExternProtoDeclare statement could identify themselves with a special url value or urn. Such extension ProtoDeclare statements would not have a Protobody.
> >
> >
> >
> > Example:
> >
> >
> >
> > <ExternProtoDeclare name="Appearance" url='"x3d_field_extension"'> <field name='material'
> >
> > type='SFNode'
> >
> > accessType='inputOutput'/><field name='material'
> >
> > type='SFNode'
> >
> > accessType='inputOutput'/>
> >
> > <field name='acousticProperties'
> >
> > type='SFNode'
> >
> > accessType='inputOutput'/>
> >
> > ...(many more}
> >
> > <field name='sortKey'
> >
> > type='SFFloat'
> >
> > accessType='initializeOnly'/> </ExternProtoDeclare>
> >
> >
> >
> > (Still need a default value for the new field somehow)
> >
> >
> >
> > and
> >
> >
> >
> > <Shape>
> >
> > <ProtoInstance name="Appearance">
> >
> > <fieldValue name='sortKey' value='1'/>
> >
> > <fieldValue name='material'>
> >
> > <Material />
> >
> > </fieldValue>
> >
> > </ProtoInstance>
> >
> > <Box/>
> >
> > <Shape>
> >
> >
> >
> > alongside regular Appearance
> >
> >
> >
> > <Shape>
> >
> > <Appearance>
> >
> > <Material />
> >
> > </Appearance>
> >
> > <Box/>
> >
> > <Shape>
> >
> >
> >
> > This seems pretty ugly and hard to process compared to a simple Metadata node, appended. So this does not seem to be the solution.
> >
> >
> >
> > Perhaps there are other ideas, Andreas
> >
> >
> >
> > On Mon, Jul 3, 2023 at 9:35 PM Brutzman, Donald (Don) (CIV) <brutzman at nps.edu> wrote:
> >
> > >
> >
> > > Acknowledged all, thanks.
> >
> > >
> >
> > >
> >
> > >
> >
> > > The way to use a prototype to only extend the fields in a node is to declare a new prototype node containing the original node as first node, include the original fields with IS connections (as appropriate) then add new fields of interest.
> >
> > >
> >
> > >
> >
> > >
> >
> > > Example follows, preserving original fields and adding an ‘enabled’ field.
> >
> > >
> >
> > >
> >
> > >
> >
> > > X3D Example Archives: X3D4WA, X3D for Web Authors, Chapter 14
> >
> > > Prototypes, Material Modulator Mimic a Material node and modulate the diffuseColor field as an animation effect, provided as a prototype for reusability.
> >
> > > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fx3dg
> >
> > > raphics.com%2Fexamples%2FX3dForWebAuthors%2FChapter14Prototypes%2FMate
> >
> > > rialModulatorIndex.html&data=05%7C01%7Cbrutzman%40nps.edu%7C31fd04678e
> >
> > > 08441ede2e08db7c38fd08%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C63
> >
> > > 8240357204635872%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
> >
> > > 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=mBBcdr8a%2
> >
> > > FU%2BPiW1ziMOnVdpZuHYd30eLR9ChAvmfLGc%3D&reserved=0
> >
> > > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fx3dg
> >
> > > raphics.com%2Fexamples%2FX3dForWebAuthors%2FChapter14Prototypes%2FMate
> >
> > > rialModulator.x3d&data=05%7C01%7Cbrutzman%40nps.edu%7C31fd04678e08441e
> >
> > > de2e08db7c38fd08%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C63824035
> >
> > > 7204635872%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzI
> >
> > > iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=X9iYcy9GCO5z8zqg
> >
> > > RoQ2XKMiWnFJA1pOAzA9KauptCo%3D&reserved=0
> >
> > >
> >
> > >
> >
> > >
> >
> > > X3D Example Archives: X3D4WA, X3D for Web Authors, Chapter 14
> >
> > > Prototypes, Material Modulator Examples Demonstrate multiple instances of an external prototype.
> >
> > > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fx3dg
> >
> > > raphics.com%2Fexamples%2FX3dForWebAuthors%2FChapter14Prototypes%2FMate
> >
> > > rialModulatorExamplesIndex.html&data=05%7C01%7Cbrutzman%40nps.edu%7C31
> >
> > > fd04678e08441ede2e08db7c38fd08%7C6d936231a51740ea9199f7578963378e%7C0%
> >
> > > 7C0%7C638240357204635872%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL
> >
> > > CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=Wv
> >
> > > iNgBQYwXBhmVlrgu%2FrhsB9DLT3lrzA%2FpFSJ8NSK48%3D&reserved=0
> >
> > > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fx3dg
> >
> > > raphics.com%2Fexamples%2FX3dForWebAuthors%2FChapter14Prototypes%2FMate
> >
> > > rialModulatorExamples.x3d&data=05%7C01%7Cbrutzman%40nps.edu%7C31fd0467
> >
> > > 8e08441ede2e08db7c38fd08%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C
> >
> > > 638240357204635872%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo
> >
> > > iV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=IIdrmmI7
> >
> > > kpyk%2FSWq4et75LqyjDZWr8R1G9h6yjyZ0KE%3D&reserved=0
> >
> > >
> >
> > >
> >
> > >
> >
> > > 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 graphics, virtual worlds, navy robotics
> >
> > > https://faculty.nps.edu/brutzman
> >
> > >
> >
> > >
> >
> > >
> >
> > > From: GPU Group <gpugroup at gmail.com>
> >
> > > Sent: Monday, July 3, 2023 4:05 PM
> >
> > > To: Andreas Plesch <andreasplesch at gmail.com>
> >
> > > Cc: Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>; X3D Graphics
> >
> > > public mailing list <x3d-public at web3d.org>
> >
> > > Subject: Re: [x3d-public] x3d extensions through Metadata;
> >
> > > ExternProtoDeclare also possible
> >
> > >
> >
> > >
> >
> > >
> >
> > > Tangentially related:
> >
> > >
> >
> > > a) tuple nodes in web3d: like script or protoDeclare fields - configurable field types, but that's all it is - a collection of fields.
> >
> > >
> >
> > > - and can be ROUTEd as SFNodes
> >
> > >
> >
> > > b) Blender import - where to hide non-blender nodes and information,
> >
> > > in such a way they can be exported and reconstituted in the exported
> >
> > > scene
> >
> > >
> >
> > > -Doug
> >
> > >
> >
> > >
> >
> > >
> >
> > > On Mon, Jul 3, 2023 at 3:46 PM Andreas Plesch <andreasplesch at gmail.com> wrote:
> >
> > >
> >
> > > Hi Don,
> >
> > >
> >
> > > <MetadataSet name="NewFields4.1" containerField='metadata'><!—list of
> >
> > > fields follow --></MetadataSet> would work. On the other hand, I may
> >
> > > prefer use of the reference field to avoid a level of hierarchy:
> >
> > >
> >
> > > <MetadataFloat reference="NewFields4.1" name="sortKey" value="1"
> >
> > > containerField='metadata' />
> >
> > >
> >
> > > After all, reference is supposed to be used for a well-defined class
> >
> > > of Metadata, perhaps with a Schema.
> >
> > >
> >
> > > We should keep in mind that there will be extensions which are not
> >
> > > candidates for v4.1.
> >
> > >
> >
> > > Describing the SFNode representation, I also had thought about reusing
> >
> > > ProtoInstance, with or without ProtoExternDeclare. But how would one
> >
> > > then represent extension fields to existing nodes like Shape ?
> >
> > >
> >
> > > I guess it is possible to mix and match Metadata and Proto but it
> >
> > > seems not ideal.
> >
> > >
> >
> > > Best, Andreas
> >
> > >
> >
> > >
> >
> > > On Mon, Jul 3, 2023 at 3:48 PM Brutzman, Donald (Don) (CIV)
> >
> > > <brutzman at nps.edu> wrote:
> >
> > > >
> >
> > > > Good efforts, thanks for thinking this possibility through farther.
> >
> > > > Agreed that new fields might be added this way
> >
> > > >
> >
> > > > <MetadataSet name="NewFields4.1" containerField='metadata'><!—list of fields follow --></MetadataSet> though nodes do seem trickier.
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > Another thought, belatedly: we might also use more-familiar ExternProtoDeclare constructs to define signatures for any new nodes of interest.
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > While we usually work hard to provide essential implementations in X3D for such declarations (possibly including even Script and Shader nodes), it is also possible that an X3D browser might recognize particular externproto nodes of interest and apply its own native implementation. The ExternProtoDeclare might even point to a stub that let any player read and handle them without rendering or error.
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > Then including a ProtoInstance for each usage of each new node also has familiar, simple syntax.
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > 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 graphics, virtual worlds, navy robotics
> >
> > > > https://faculty.nps.edu/brutzman
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > -----Original Message-----
> >
> > > > From: x3d-public <x3d-public-bounces at web3d.org> On Behalf Of Andreas
> >
> > > > Plesch
> >
> > > > Sent: Monday, July 3, 2023 11:51 AM
> >
> > > > To: X3D Graphics public mailing list <x3d-public at web3d.org>
> >
> > > > Subject: Re: [x3d-public] x3d extensions through Metadata
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > While Metadata could provide a backward compatible way to represent non-standard fields and nodes, it seems difficult to use such Metadata nodes for events and routes.
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > It would mean for a browser to establish implicit, internal bi-directional routes between an extension Metadata node and the actual field of a scene graph node. This becomes similar to Prototypes and quite difficult to track properly for a browser.
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > A potential solution may be to disregard extension Metadata nodes for routing to the represented nodes. Extension Metadata nodes would only be used initially to populate extension fields and add extension nodes to the scene graph.
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > In effect this means that for MetadataSets representing SFNodes it will be necessary to include another MetadataString child which defines the DEF name of the represented extension node. So the name for this MetadataString could be 'DEFname' and the value the name which can be used for routing. Unfortunately, it would not be possible to use the name field of the MetadataSet since the name field contains the node name ("Depthmode"). It is also not possible to use the DEF statement because it will refer to the Metadata node, not the represented SFNode.
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > This way there is complete information to construct the scene graph node during first loading and add it.
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > This also would mean routes with a fromNode or toNode to an extension node with a DEFname of say "readonlyDepthmask" represented by a MetadataSet would be legal even although there is no DEF statement with such a name, only the corresponding MetadataString. If validators check for routes, they would have to account for this.
> >
> > > >
> >
> > > > Similarly routes with fromField or toField to an extension field, say "sortKey", would be also legal although the field is only represented by MetadataXXX node with the name of the field.
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > Perhaps this all means that the integrity of routes cannot be completely validated if Metadata are used to represent extension fields and nodes.
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > It is probably time to put together examples for easier discussion.
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > -Andreas
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > On Sun, Jul 2, 2023 at 1:45 PM Andreas Plesch <andreasplesch at gmail.com> wrote:
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > X3D Browsers may have non-standard extensions such as fields and
> >
> > > >
> >
> > > > > nodes. It has been suggested that a backwards compatible way to
> >
> > > > > access
> >
> > > >
> >
> > > > > such extensions could be accomplished through Metadata nodes. This
> >
> > > > > way
> >
> > > >
> >
> > > > > a X3D file using such extensions still can conform strictly to the
> >
> > > >
> >
> > > > > syntactic standard.
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > It should be possible for browsers to have general and automatic
> >
> > > >
> >
> > > > > recognition of such extension fields and nodes provided in Metadata.
> >
> > > >
> >
> > > > > Here is a first draft mechanism:
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > A metadata node would advertise that it is eligible to be
> >
> > > > > considered
> >
> > > >
> >
> > > > > as an extension, probably through a reference value of say
> >
> > > >
> >
> > > > > "x3dExtension", or by being contained in a special Metadataset
> >
> > > > > with
> >
> > > >
> >
> > > > > such a name or reference.
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > Then a browser would check the Metadata name and if the name is
> >
> > > >
> >
> > > > > equivalent to an implemented field of the parent node, the browser
> >
> > > >
> >
> > > > > would use the value of the Metadata and use it in some way as the
> >
> > > >
> >
> > > > > value of the field (This could also apply to standard fields).
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > Since Metadata values can only be of type MFString, MFFloat,
> >
> > > > > MFDouble,
> >
> > > >
> >
> > > > > MFBool or MFInt32 there needs to be some translation to field values.
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > Most translations are obvious but SF/MFNode fields are not. One
> >
> > > > > option
> >
> > > >
> >
> > > > > is to provide the xml string of an SFNode as the value in a
> >
> > > >
> >
> > > > > MetadataString node. But this may be too encoding specific. On the
> >
> > > >
> >
> > > > > other hand there is the standard SAI function
> >
> > > > > createX3DFfromString
> >
> > > >
> >
> > > > > for that.
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > So another option is to use MetadataSet for SFNode. name would
> >
> > > > > still
> >
> > > >
> >
> > > > > be the field name for the SFNode. Then the children of MetadataSet
> >
> > > >
> >
> > > > > would contain the fields of the SFNode node. In addition there
> >
> > > > > would
> >
> > > >
> >
> > > > > be a MetadataString node with name "nodeName" which has the node
> >
> > > > > name
> >
> > > >
> >
> > > > > as the value. This is more verbose but crosses encodings.
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > MFNode fields would also use MetadataSet. The only children would
> >
> > > > > be
> >
> > > >
> >
> > > > > MetadataSet of the SFNode kind.
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > I will have to check how well that kind of mechanism would fit
> >
> > > > > with
> >
> > > >
> >
> > > > > processing of metadata in x3dom. It may not fit that well.
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > Any feedback, or ideas welcome,
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > Andreas
> >
> > > >
> >
> > > > > --
> >
> > > >
> >
> > > > > Andreas Plesch
> >
> > > >
> >
> > > > > Waltham, MA 02453
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > --
> >
> > > >
> >
> > > > Andreas Plesch
> >
> > > >
> >
> > > > Waltham, MA 02453
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > _______________________________________________
> >
> > > >
> >
> > > > x3d-public mailing list
> >
> > > >
> >
> > > > x3d-public at web3d.org
> >
> > > >
> >
> > > > http://web3d.org/mailman/listinfo/x3d-public_web3d.org
> >
> > >
> >
> > >
> >
> > >
> >
> > > --
> >
> > > Andreas Plesch
> >
> > > Waltham, MA 02453
> >
> > >
> >
> > > _______________________________________________
> >
> > > x3d-public mailing list
> >
> > > x3d-public at web3d.org
> >
> > > http://web3d.org/mailman/listinfo/x3d-public_web3d.org
> >
> >
> >
> >
> >
> >
> >
> > --
> >
> > Andreas Plesch
> >
> > Waltham, MA 02453
>
>
>
> --
> Andreas Plesch
> Waltham, MA 02453
--
Andreas Plesch
Waltham, MA 02453
More information about the x3d-public
mailing list