forked from x3dom/x3dom
-
Notifications
You must be signed in to change notification settings - Fork 0
Logging
Andreas Plesch edited this page Nov 15, 2019
·
13 revisions
> >> a browser feature which can be set in
> >> the browser interface, or as a PARAM for html as other browser
> >> properties:
> <X3D id="x3d" showLog="true" logLevel='5' >
Browser properties could be a fitting abstract place.
two browser properties, currentLogLevel
(or just logLevel) and maxLogLevel. Both are set initially to the logLevel
value provided by the scene.
currentLogLevel can then be modified by a sai browser service. This could
be done from a GUI, or from a script. But it is not allowed to become
higher than maxLogLevel.
In order to respect logging restrictions, eg. logLevels, in Inlines,
maxLogLevel could be per name scope, or more simply just be lowered in
general by restricted Inlines.
it suffices to just focus on the ROUTE level logging since
these events are usually the only one of interest.
https://www.web3d.org/documents/specifications/19775-2/V3.3/Part02/servRef.html#setBrowserOption
Data logging is a common prerequisite for many types of measurement and assessment. Currently, achieving logging capabilities requires custom script nodes be embedded into a scene, or use of a debugger. Standardizing a logging feature in X3D will have a number of benefits:
- efficient post-processing of logging output based on a reliable format
- minimal modification of existing scenes to enable logging
- control by scene author of amount of information revealed by logging
A design which accommodates these goals is proposed.
To accommodate stated design goals, a global logging feature acting on a scene wide level is proposed. The X3D browser gains a capability to switch logging on or off while respecting scene content restrictions on logging. Only events which participate in routes, and only events in the name scope of the main scene are logged. These restrictions protect the security of Inline or Prototype name scopes. If logging of events internal to Inline or Prototype nodes is required, such events have to be explicitly made available to the main scene via EXPORT/IMPORT statements or Prototype interfaces. Logging output is directed to the Browser console, and is provided in an easy to parse, well defined, textual format.
The specification mechanism to achieve this capability are Browser options which can be accessed via the Scene Access Interface (SAI).
Section 9.2.4 lists currently available browser options. A new option 'LogLevel' is proposed. Setting this option with a browser specific method as outlined in the section requests logging from a X3D browser. The browser then is required to restrict logging as defined in scene content by a Metadata string value of name 'maxLogLevel'.
Table 9.2 amendment:
| Name | Description | Type/valid range | Default |
|---|---|---|---|
| LogLevel | Log routed events | None, Full | None |
The SAI defines a setBrowserOption service.
Support for 'None' and 'Full' is required. 'None' switches off logging completely, producing no output to the console. 'Full' switches logging on for all events which participate in ROUTE statements.
A browser may choose to allow intermediate values. For example, a 'Sensors' value would cause logging of Sensor events only.
Logging output is textual in UTF-8 encoding. Each event is logged on one line to the Browser console. Output string formatting is based on a need for legal values in the XML encoding corresponding to each type (for example, SFTime is a double-precision float). Values are separated by a comma (with no whitespace). Comment lines are allowed and encouraged for clarity,and begin with '#'. Examples:
# timestamp, sending node type, DEF name, field name, field type, field value
9876432.10,Material,myMaterial,diffuseColor,SFColor,0.1 0.2 0.3
9876432.20,Text,myTextNode,string,MFString,'"Hello" "Cruel,Comma"'
The scope of logging is limited to events generated by nodes in the name scope of the main scene currently loaded by the browser. This restriction is based on security consideration protecting potentially encrypted Inline content or Prototype nodes. If logging of events internal to Inline nodes or Prototype instances is desired, such events can be made available to the main scene with EXPORT/IMPORT statements or the Prototype interface.
Only events which participate in ROUTE statements are logged. This requirement is a mechanism to select the events most relevant to the scene and generated by scene nodes for logging, without requiring additional intervention. It is also a mechanism which allows for investigating any event of interest simply by adding a ROUTE statement.
Scene authors may wish to restrict logging. For this purpose, a scene can include a MetadataString node with name "maxLogLevel" and the desired logging level as value (for example, "None") in a WorldInfo node, optionally contained in a MetadataSet. A browser is required to restrict logging to this value, regardless of what 'logLevel' value is currently set as a Browser option. Please note that if scene content is available in editable form to a user, there is no possibility of securing content.
Other than amending table 9.2, no changes to the SAI specifications are required.
A NOTE has been added to this issue.
======================================================================
https://www.web3d.org/member-only/mantis/view.php?id=1263
======================================================================
Reported By: brutzman
Assigned To: andreasplesch
======================================================================
Project: X3D
Issue ID: 1263
Category: 19775-1 (Abstract)
Tags: V4.0
Reproducibility: have not tried
Severity: feature
Priority: normal
Status: assigned
======================================================================
Date Submitted: 2019-10-16 08:22 PDT
Last Modified: 2019-10-25 09:02 PDT
======================================================================
Summary: Log capability to record event streams
Description:
Data logging is a common prerequisite for many types of measurement and
assessment.
Conventions for logging via HTML and also directly via X3D need to be
considered. For example, numerous X3D sensor nodes include the ability to
generate output events triggered by user navigation and interaction. Common
data formatting that identifies system parameters, event source, timestamp and
data streams for a given scene can facilitate analysis. Defining and adding a
logging function to the X3D Browser object specification can enable secure
recording of information.
Logging capabilities are expected to have significant benefits for X3D
implementations and user experience (UX)
Additional Information:
Logging in this context is local. Remote logging is not something that we need
to specify in X3D. Applications can do that independently, and so can
server-connected HTML pages.
Security considerations are important. For example, we might note that players
can turn off logging by default and require user permissions to utilize it.
Michalis Kamburelis reports:
http://web3d.org/pipermail/x3d-public_web3d.org/2019-October/011370.html
Instant Reality and Castle Game Engine implement a "Logger" node, that
seems in line with your thinking It was indeed quite useful in some
cases when I wasn't sure what/when events are generated by something.
See:
- https://doc.instantreality.org/documentation/nodetype/Logger/ ( note
that the CSS of Instant Reality docs seems broken for me now, but the
content is readable anyway)
- https://castle-engine.io/x3d_extensions.php#section_ext_logger (
it's a long page, look at section about "Logger" )
The principle is simple: route *anything* to Logger's "write" field to
output it to browser-specific log mechanism. A special type is
invented here to allow an input event to receive any X3D field type:
XFAny .
I would say that adding it to X3D spec may be reasonable (but without
the "logFile" field), in the "Event Utilities" component --
implementing this node is rather easy, and the usefulness is real.
Example in classic encoding:
"""
DEF MyLogger Logger {
level 3
}
DEF MyKeySensor KeySensor { }
ROUTE MyKeySensor.keyPress TO MyLogger.write
"""
Complete example that works in view3dscene:
https://github.com/castle-engine/demo-models/blob/master/x3d/castle_extensions/logger.x3dv
======================================================================
----------------------------------------------------------------------
(0002463) brutzman (developer) - 2019-10-16 16:29
https://www.web3d.org/member-only/mantis/view.php?id=1263#c2463
----------------------------------------------------------------------
Spec editor discussion: adding type "XFAny" is vague and somewhat problematic.
XFAny [in] write
Preferred name would be more descriptive, such as "logValue" for example.
This field represents an exhaustive set of explicitly defined input fields for
all types, e.g.
SFBool [in] logValue
MFBool [in] logValue
SFInt32 [in] logValue
MFInt32 [in] logValue
SFFloat [in] logValue
… and so on.
Authors don't perform type conversion, the Logger does type conversion. The
specification prose needs to clearly reflect this. Perhaps each and every type
needs to be listed so that no confusion is possible.
----------------------------------------------------------------------
(0002464) brutzman (developer) - 2019-10-16 16:41
https://www.web3d.org/member-only/mantis/view.php?id=1263#c2464
----------------------------------------------------------------------
More detail is needed on output format. This is the primary value of log files,
they are readable.
Multiple levels is counterproductive. Single format needs to be consistently
provided, so that parsing and analysis is consistently possible. Output strings
need to be legal values corresponding to each type (for example, SFTime is a
double-precision float). Values are separated by a comma (with no whitespace).
Comments are allowed for clarity. Examples:
# timestamp, sending node type, DEF name, field name, field type, field value
9876432.10,Material,myMaterial,diffuseColor,SFColor,0.1 0.2 0.3
9876432.20,Text,myTextNode,string,MFString,'"Hello" "Cruel,Comma"'
----------------------------------------------------------------------
(0002465) brutzman (developer) - 2019-10-16 16:56
https://www.web3d.org/member-only/mantis/view.php?id=1263#c2465
----------------------------------------------------------------------
Corresponding SAI Browser service does not need to be defined, since an author
might have multiple Logger nodes active.
Design question with security consideration:
a. do multiple Logger nodes each use a different file, or
b. does Logger need a name, which gets prefixed to the output string above?
Also: the Logger node signature needs an output field so that authors can have
access to the log entry, allowing authors to inspect or display what is getting
logged. For example:
SFString [out] logEntry
Besides being a useful capability, not being able to see what is written is a
security shortcoming.
----------------------------------------------------------------------
(0002473) brutzman (developer) - 2019-10-25 09:02
https://www.web3d.org/member-only/mantis/view.php?id=1263#c2473
----------------------------------------------------------------------
Further details and considerations in X3D Working Group minutes 25 OCT 2019.
MIME-Version: 1.0
Date: Fri, 25 Oct 2019 16:18:48 -0400
References: <[email protected]> <CAKdk67vZfd_5jB-B9vWnJx++eEMBY5AyRKfC9K5Wf1NMKoaq=w@mail.gmail.com> <CAKdk67vCP=-QjZgWeEm-t20WOAbf+Vg7pf7vmRRn=zYcoqeevw@mail.gmail.com> <[email protected]> <CAKdk67vq4nEWSPErLdY1h4XCF6Ok3yJ0Uw3ZV52cUyJzA3_WNA@mail.gmail.com> <CAKdk67sB0txvv7npkjHf11PeFdq5bAS52rxh2x4H+EXgW_NRwQ@mail.gmail.com> <[email protected]>
In-Reply-To: <[email protected]>
Message-ID: <CAKdk67vesQAevKsJx3YyV72-e3m9ofDo0wVCrghksvZK3hhMuA@mail.gmail.com>
Subject: Re: [x3d-public] Data logging support in X3Dv4
From: Andreas Plesch <[email protected]>
To: Don Brutzman <[email protected]>
Cc: X3D Graphics public mailing list <[email protected]>
Content-Type: multipart/alternative; boundary="0000000000009498370595c1dbda"
--0000000000009498370595c1dbda
Content-Type: text/plain; charset="UTF-8"
On Thu, Oct 24, 2019, 8:14 PM Brutzman, Donald (Don) (CIV) <[email protected]>
wrote:
> Thanks for the great example - impressive!
>
> Getting explicit to match your description, it looks like the key
> statement is
>
> <X3D id="x3d" showLog="true" logLevel='5' width="800px"
> height="600px">
>
Yes, that is the interface in the example, attributes to the X3D root.
This probably needs to stay abstract in the abstract spec.
Browser properties could be a fitting abstract place.
Not sure how other than XML encodings would store such a setting.
> Adding it to X3D root would seem to work for X3D applications in a
> non-HTML context as well. Also makes it easy for any author, and possible
> for any model (not requiring Script node). Thus meets goal of easy
> repeatability too.
>
> Is this approach (attributes on X3D root) acceptable with everyone,
> including FreeWrl view3dscene and other standalone application environments?
>
The spec. also mentions config files for browser properties, as an example.
> If so, wondering if we are ready to tackle other attributes on X3D element
> (such as id width height url)?
>
> Once we agree on basic approach, we should also discuss whether scoping of
> logging is possible. Can it be turned off for parts of scene graph, does
> it affect internals within Inline and ProtoInstance, etc.
>
In my view, it should be simple and not (very) configurable. So I would
suggest logging any ROUTE in child name scopes, in Inlines and also in
ProtoInstances. The logging output could include a name scope id.
This brings up control of logging by a scene author. Would an additional
maxLogLevel root property be required ? Maybe not.
I am thinking that there would be two browser properties, currentLogLevel
(or just logLevel) and maxLogLevel. Both are set initially to the logLevel
value provided by the scene.
currentLogLevel can then be modified by a sai browser service. This could
be done from a GUI, or from a script. But it is not allowed to become
higher than maxLogLevel.
In order to respect logging restrictions, eg. logLevels, in Inlines,
maxLogLevel could be per name scope, or more simply just be lowered in
general by restricted Inlines.
Good topic for issue review on X3D Working Group call Friday morning.
> Participating in the discussion and email feedback are both welcome.
>
I will try to come up with more specifics for spec. purposes.
-Andreas
>
> v/r Don
>
>
> On 10/20/2019 3:18 PM, Andreas Plesch wrote:
> > Here is an example implementation using a new attribute 'logLevel' to
> > the X3D element, working as a browser property interface>
> >
> https://raw.githack.com/andreasplesch/x3dom/dcde5c67281c1a3dae6b20b1944065d24d369711/test/functional/widgetPlaneSensor.html
> >
> > logLevels 5 and higher turn on event logging.
> >
> > [For x3dom it may make sense to reserve lower levels for system level
> > logging: exceptions, errors, warnings, information]
> >
> > The format here is FROM node type, node def name (or null), field
> > name, field value
> >
> > Perhaps it suffices to just focus on the ROUTE level logging since
> > these events are usually the only one of interest.
> >
> > The 'trace' attribute in x_ite_dom has a similar effect (except not
> > restricted to ROUTEd events).
> >
> > So two implementations of such a logging feature may not be out of reach.
> >
> > -Andreas
> >
> > On Sun, Oct 20, 2019 at 3:58 PM Andreas Plesch <[email protected]>
> wrote:
> >>
> >> On Sat, Oct 19, 2019 at 2:04 AM Brutzman, Donald (Don) (CIV)
> >> <[email protected]> wrote:
> >>>
> >>> Thanks for the great analysis Andreas.
> >>>
> >>> Sorry for mystery assignment... we do need someone to take charge of
> this one. Can defer to someone else if you prefer.
> >>>
> >>> There is much to be said for Logger staying directly aligned with
> Browser services. But, if that is where we leave it, am expecting that
> logging will be rarely used because use of Browser services requires a
> Script node and adaptation code - tedious and inconsistent. Much better
> for encouraging use is to also have a consistently defined Logger node that
> any author can configure or ROUTE to, in any scene, for consistent testing
> and conformance/QA.
> >>
> >> I would envision logging to be a browser feature which can be set in
> >> the browser interface, or as a PARAM for html as other browser
> >> properties:
> https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/networking.html#BrowserProperties
> .
> >> x3dom uses an Environment node to set various Browser options. It
> >> would be very easy to use. The point is that it is easier to use than
> >> a Logger node because it would not require modifying the content of
> >> the scene.
> >>
> >> The browser option would be make a Logger node unnecessary. So the
> >> spec. would not have to define a Logger node.
> >>
> >>>
> >>> Quote: "when you come to the fork in the road, take it" - Yogi Berra
> >>>
> >>> Hmmm, I guess we need to put such a Logger node in Core profile for
> full generality and usefulness.
> >>>
> >>> Are you saying that logLevel is for automatic logging of all events,
> rather than explicitly ROUTEd input values? Interesting possibility... if
> so, once again we might achieve best of both worlds by having one logLevel
> setting be for ROUTEd input values only. That would seem to give authors
> both simple flexibility and fine-grained control.
> >>
> >> Yes. Only ROUTEd events was one of the LogLevels I had listed (the
> first one).
> >>
> >>>
> >>> Am willing to create a Prototype that at least creates a Script node
> console log illustrating proper text outputs. (File saving not allowed in
> Script node sandbox.)
> >>
> >> That would be useful in any case.
> >>
> >>>
> >>> Looks like the variations of logging support desired for a given model
> can all be expressed in the Logger node itself, meaning that we wouldn't
> have to modify any X3D/head/Scene parameters. Simple is good.
> >>
> >> Yes, but it is even simpler to not have to have a Logger node. It
> >> would be just a matter of switching on Logging in the browser. No
> >> scripting required.
> >>
> >> Best, -Andreas
> >>
> >>>
> >>> I agree that we seem to be getting closer on this one.
> >>>
> >>> On 10/18/2019 12:08 PM, Andreas Plesch wrote:
> >>>> I received a mystery email from the Mantis tracker about being
> >>>> assigned a Logger entry. The forwarded Mantis summary seems pretty
> >>>> comprehensive. It focuses on a Logger node.
> >>>>
> >>>> Another way to think about logging of events is as a browser feature
> >>>> which can be enabled, parallel to a debugger. This is how I would
> >>>> first think about logging. As a system feature, not as a scene content
> >>>> feature. It seems counterproductive to have to modify/augment a scene
> >>>> with extra nodes, scripts and routes to enable logging.
> >>>>
> >>>> So my suggestions would be to turn this into a Browser Property or
> >>>> Browser Option. Scene's could hint with a SAI script what level of
> >>>> logging they allow, expecting the browser to respect the hint. Note
> >>>> that a Logger node would not prevent browsers from unauthorized
> >>>> logging if a browser really wanted to.
> >>>>
> >>>> Is the main security concern that with logging an otherwise protected
> >>>> scene (perhaps by encryption) would expose its data (geometry, raw
> >>>> imagery) ?
> >>>>
> >>>> Enabled logging would just log output events by nodes selected by
> >>>> loglevel, always to the console (which may be recorded in a file
> >>>> anyways), in a standard format as outlined in the Mantis summary.
> >>>> Filtering can be applied by other tools. There are a lot of events
> >>>> zipping around.
> >>>>
> >>>> loglevels could be combinations of:
> >>>> - ROUTES: only events which go through routes
> >>>> - Sensors: events generated by any Sensor
> >>>> - Scripts: events generated by Scripts
> >>>> - Interpolators/Sequencers: events generated by those
> >>>> - component: events generated by all nodes defined in a component
> ("Networking")
> >>>> - all: deluge from all nodes
> >>>> - none: no logging, default
> >>>>
> >>>> I suppose one way to think about this as a browser feature is to have
> >>>> implicit Logger nodes and routes from all the nodes selected by
> >>>> loglevels. The advantage from a spec. perspective that the mechanism
> >>>> does not have to be explicitly prescribed, only the functionality.
> >>>>
> >>>> So I think it boils down to:
> >>>>
> >>>> a) What is the standard format of the logging output ? Perhaps easy
> to define.
> >>>>
> >>>> b) What is logged ? output events of some or all nodes.
> >>>>
> >>>> c) The browser service specification:
> >>>>
> >>>> - it may be possible to piggy back on setBrowserOption which uses this
> >>>> table:
> https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/networking.html#t-BrowserProperties
> >>>> :
> >>>> add a property:
> >>>> Name: LogLevel
> >>>> Description: allow logging of events to console
> >>>> Range: see above
> >>>> Default: None
> >>>>
> >>>> And perhaps a header (meta?) entry 'maxLogLevel' in the Scene to limit
> >>>> logging, by a Scene author:
> >>>>
> https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/core.html#HeaderStatement
> .
> >>>> Or allow resetting of the Browser Option by the Scene with an
> >>>> initialize script.
> >>>>
> >>>> I think once a more precise spec. language is provided, multiple
> >>>> browser implementation could be quickly had.
> >>>>
> >>>> Any feedback welcome.
> >>>>
> >>>> -Andreas
> >>>>
> >>>> On Wed, Oct 16, 2019 at 10:27 PM Andreas Plesch <
> [email protected]> wrote:
> >>>>>
> >>>>> x_ite_dom can log all out events by adding a 'trace' attribute to
> the x3dcanvas element.
> >>>>>
> >>>>> x3dom does not have built-in logging . Instead, all web browsers
> have powerful debuggers which can be used to follow the event flow (and all
> internals). Chrome even lets you modify code and then continue, or restart.
> >>>>>
> >>>>> This also applies to x_ite.
> >>>>>
> >>>>> Andreas
> >>>>>
> >>>>> ---on the phone---
> >>>>>
> >>>>> On Wed, Oct 16, 2019, 6:40 PM <[email protected]> wrote:
> >>>>>>
> >>>>>> Send x3d-public mailing list submissions to
> >>>>>> [email protected]
> >>>>>>
> >>>>>> To subscribe or unsubscribe via the World Wide Web, visit
> >>>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
> >>>>>> or, via email, send a message with subject or body 'help' to
> >>>>>> [email protected]
> >>>>>>
> >>>>>> You can reach the person managing the list at
> >>>>>> [email protected]
> >>>>>>
> >>>>>> When replying, please edit your Subject line so it is more specific
> >>>>>> than "Re: Contents of x3d-public digest..."
> >>>>>>
> >>>>>>
> >>>>>> Today's Topics:
> >>>>>>
> >>>>>> 1. Re: Data logging support in X3Dv4 (Brutzman, Donald (Don)
> (CIV))
> >>>>>>
> >>>>>>
> >>>>>>
> ----------------------------------------------------------------------
> >>>>>>
> >>>>>> Message: 1
> >>>>>> Date: Wed, 16 Oct 2019 15:31:25 +0000
> >>>>>> From: "Brutzman, Donald (Don) (CIV)" <[email protected]>
> >>>>>> To: Michalis Kamburelis <[email protected]>
> >>>>>> Cc: X3D Graphics public mailing list <[email protected]>, Feng
> Liu
> >>>>>> <[email protected]>
> >>>>>> Subject: Re: [x3d-public] Data logging support in X3Dv4
> >>>>>> Message-ID: <[email protected]>
> >>>>>> Content-Type: text/plain; charset="utf-8"
> >>>>>>
> >>>>>> Thank you very much for this detailed information Michalis.
> >>>>>>
> >>>>>> I have created Mantis issue 1263 to track this.
> >>>>>>
> >>>>>> * https://www.web3d.org/member-only/mantis/view.php?id=1263
> >>>>>>
> >>>>>> Who would like to take charge of the issue: Next steps include:
> >>>>>>
> >>>>>> - reconciling implementations X3DOM, Castle Game Engine and adding
> others (X_ITE, FreeWrl, etc.),
> >>>>>> - one or two example scenes (with outputs) to confirm conformance,
> >>>>>> - draft specification prose, including security considerations.
> >>>>>>
> >>>>>> We can all assist via the mailing list. Having someone in charge
> will help.
> >>>>>>
> >>>>>> On 10/14/2019 11:58 PM, Michalis Kamburelis wrote:
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> Instant Reality and Castle Game Engine implement a "Logger" node,
> that
> >>>>>>> seems in line with your thinking :) It was indeed quite useful in
> some
> >>>>>>> cases when I wasn't sure what/when events are generated by
> something.
> >>>>>>>
> >>>>>>> See:
> >>>>>>> - https://doc.instantreality.org/documentation/nodetype/Logger/ (
> note
> >>>>>>> that the CSS of Instant Reality docs seems broken for me now, but
> the
> >>>>>>> content is readable anyway)
> >>>>>>> - https://castle-engine.io/x3d_extensions.php#section_ext_logger (
> >>>>>>> it's a long page, look at section about "Logger" )
> >>>>>>>
> >>>>>>> The principle is simple: route *anything* to Logger's "write"
> field to
> >>>>>>> output it to browser-specific log mechanism. A special type is
> >>>>>>> invented here to allow an input event to receive any X3D field
> type:
> >>>>>>> XFAny .
> >>>>>>>
> >>>>>>> I would say that adding it to X3D spec may be reasonable (but
> without
> >>>>>>> the "logFile" field), in the "Event Utilities" component --
> >>>>>>> implementing this node is rather easy, and the usefulness is real.
> >>>>>>>
> >>>>>>> Example in classic encoding:
> >>>>>>>
> >>>>>>> ```
> >>>>>>> DEF MyLogger Logger {
> >>>>>>> level 3
> >>>>>>> }
> >>>>>>> DEF MyKeySensor KeySensor { }
> >>>>>>> ROUTE MyKeySensor.keyPress TO MyLogger.write
> >>>>>>> ```
> >>>>>>>
> >>>>>>> Complete example that works in view3dscene:
> >>>>>>>
> https://github.com/castle-engine/demo-models/blob/master/x3d/castle_extensions/logger.x3dv
> >>>>>>>
> >>>>>>> Regards,
> >>>>>>> Michalis
> >>>>>>>
> >>>>>>> pon., 14 pa? 2019 o 19:24 Brutzman, Donald (Don) (CIV)
> >>>>>>> <[email protected]> napisa?(a):
> >>>>>>>>
> >>>>>>>> [We explored several points such as this during today's Web3DUX
> User Experience teleconference.]
> >>>>>>>>
> >>>>>>>> Data logging is a common prerequisite for many types of
> measurement and assessment.
> >>>>>>>>
> >>>>>>>> Conventions for logging via HTML and also directly via X3D need
> to be considered. For example, numerous X3D sensor nodes include the
> ability to generate output events triggered by user navigation and
> interaction. Common data formatting that identifies system parameters,
> event source, timestamp and data streams for a given scene can facilitate
> analysis. Defining and adding a logging function to the X3D Browser object
> specification can enable secure recording of information.
> >>>>>>>>
> >>>>>>>> Question: do others think that logging is important also? Am
> thinking that having such a capability is important for measurable
> improvements in X3Dv4.
> >>>>>>>>
> >>>>>>>> all the best, Don
> >>>>>>>> --