[x3d-public] view3dscene and X3D4: attributes id, class and style
Brutzman, Donald (Don) (CIV)
brutzman at nps.edu
Sun Oct 3 07:50:50 PDT 2021
Thanks Michalis for continued scrutiny in this long and interesting email thread. I’ve copied x3d-public with your permission so that we have an mailing-list archive record and broader consideration from others. (Anyone interested in this discussion topic is encouraged to start at the bottom of the thread and work back up through the progression of ideas.)
Responses to your most recent three points:
Point 1. Some version of your sentence for Annex L is probably a good idea. Dick and I will discuss whether it makes editorial sense in an upcoming editing meeting. Still to be determined is what additional information should be described in “19776-1 X3D Encoding: XML” and what gets included in related supporting documents. Meanwhile X3D Tooltips are non-normative and a good place to express intent for authors.
Point 2. Agreed that clarity is always good. Previously we tried to see if just using nodes was sufficient. However it quickly became clear that DOM activity might have any number of purposes for these attributes: authoring/construction, search, presentation styling, etc. that have no particular relation to the scene graph per se. And so, simply took a document-wide approach and included the entire element vocabulary, as HTML itself does. Currently both XML Schema and DTD cover all elements (nodes and statements) to avoid any possibility of future gaps. Where this concept gets expressed (i.e. in which X3D specifications) is closely related to Point 1.
Point 3. Actually, since support for id/class/style is present in X3D XML Schema, these attributes are already included and engineered as part of X3DUOM and Java X3DJSAIL and Python X3DPSAIL x3d.py and X3D Ontology. When we revisit (hopefully this quarter) John and I will likely integrate them into an autogenerated X3D JSON Schema as well. No reason why they might not be added to X3D4 ClassicVRML Encoding as well, since they are treated effectively as comments in our X3D conversion to .x3dv or .wrl by X3dToVrml97.xslt stylesheet.
* https://x3dgraphics.com/examples/X3dForAdvancedModeling/HelloWorldScenes/HelloWorldX3D4Index.html
* https://x3dgraphics.com/examples/X3dForAdvancedModeling/HelloWorldScenes/HelloWorldX3D4.x3dv
* https://x3dgraphics.com/examples/X3dForAdvancedModeling/HelloWorldScenes/HelloWorldX3D4.wrl
DEF WorldInfoSecondary WorldInfo {
### class='TestClass'
### id='TestID'
### style='TestStyle'
title "test HTML CSS fields"
}
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 http://faculty.nps.edu/brutzman
From: Michalis Kamburelis<mailto:michalis.kambi at gmail.com>
Sent: Saturday, October 2, 2021 6:22 PM
To: Brutzman, Donald (Don) (CIV)<mailto:brutzman at nps.edu>
Subject: Re: view3dscene and X3D4: attributes id, class and style
Thank you for the answers.
To be clear, I'm actually fine with all this. I mean, my points below 1, 2, 3 are all an acceptable resolution. But I do feel we need to document these things clearly, for all X3D authors, in Annex L, so that it is clear to all X3D authors and implementors. There's no perfect solution here, we should go with the solution you propose, but document it's limitation (my point 3 below).
1. The browsers that do not put X3D in DOM, like view3dscene, should treat the id/style/class as valid in X3D XML, and do nothing. As id/style/class attributes are correct in X3D XML, and do nothing when content is not in DOM. OK.
I'd like "Annex L" to explicitly say this sentence somewhere in https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/Part01/htmlGuidelines.html . Like """The browsers that do not put X3D in DOM should still treat the id/style/class attributes as valid in X3D XML. These attributes do nothing when X3D is not part of DOM.""""
I get that CGE/view3dscene can still show a warning (like "hey, id/style/class does nothing in this browser") but it is CGE/view3dscene decision. The content is still valid X3D XML.
2. Annex L should say explicitly on which XML elements it is allowed. From your answers and tooltips I get that the answer is "on all of them". This includes a few things:
- all nodes
- <ROUTE>
- <IMPORT> <EXPORT>
- <ProtoBody> <ProtoDeclare> <ProtoInstance> <ProtoInterface>
- <Scene>
- <X3D>
- <USE>
This is all OK -- but, again Annex L prose should make it clear. E.g. say """The id/style/class are allowed on all XML elements, not just on nodes.""" .
3. We should admit then that we somewhat forfeit one feature you mentioned:
""""
b. we want all of the languages and encodings to have equivalent expressive power, allowing them to be later published in XML form for use inside HTML/DOM.
""""
If we cannot record id/style/class in other than XML encodings, then the lossless trip XML encoding -> classic encoding -> XML encoding is not possible. The "classic encoding" cannot encode the id/style/class. It is not an X3D field. And it can occur on many things (not just nodes) according to AD 2, so we cannot even easily extend "classic encoding" to preserve id/style/class in every possible scenario.
I am OK with such decision (because there's no perfect solution here), but I want to mention this explicitly. X3D authors should also be aware of that. "When converting X3D to an non-XML encoding, you may lose the id/style/class information" --- "Annex L" should just say it explicitly.
In case of CGE/view3dscene, even a conversion XML encoding -> XML encoding will just strip the id/style/class information, at least in case of non-nodes (e.g. if you write <ProtoInstance style="xxx" />. Since we don't store the original XML tree, we don't have an easy way to record id/style/class information at an arbitrary XML node. You can say this is just a limitation of CGE/view3dscene, though I will speculate that all X3D browsers that don't put X3D content in DOM (like FreeWRL) will land in the same problem.
P.S. Feel free to repost everything from this thread to x3d-public :)
Regards,
Michalis
niedz., 3 paź 2021 o 02:23 Brutzman, Donald (Don) (CIV) <brutzman at nps.edu<mailto:brutzman at nps.edu>> napisał(a):
Thanks for your note and considering this issue. Hoping to discuss as needed.
I have no problems with warnings provided by tools, they are optional. We might also include warnings as part of X3D Schematron if people thought that was useful – ongoing practice will probably help us to decide that. If you want to keep providing warnings, that it is up to you; you might want to include a little more information in those warnings. Your idea that tools might strip these attributes for use in other contexts is a good one, I will think about how to add that to X3DJSAIL and x3d.py packages as utility methods.
Nevertheless XML Schema and XML DOCTYPE (DTD) do not have an option for providing warnings, so an XML document is either valid (with no errors) or not.
I had originally thought we might be able to avoid any special treatment of these fields (similar to your position described here, I suppose). However
1. there is no practical way to add id/class/style information to an X3D mode after it is authored, it is contextual.
2. we want all of the languages and encodings to have equivalent expressive power, allowing them to be later published in XML form for use inside HTML/DOM.
3. we can’t have X3D models that are valid in one context but invalid in another context, since that breaks compatibility and interoperability and maintainability.
Of course FontStyle/ScreenFontStyle have name collisions between X3D style field and HTML style attribute, that is difficult. X3D field “wins” of course.
Am having a little difficulty with your paragraph “Until we have a clear specification…” We already have Annex L HTML Guidelines, and it does mention all three HTML attributes. So they are allowed by the X3D4 Architecture specification. If we need to say something clearer there, then let’s create a Mantis issue describing the problem clearly (and hopefully offering a candidate solution or two). Whatever improvements we figure out might actually be better placed in X3D XML specification document, when we get there. Agreed that non-HTML browsers such as view3dscene should warn as they think best.
This information is provided in X3D Tooltips might be helpful examples for how to find the right balance. Improvements always welcome.
* https://www.web3d.org/x3d/content/X3dTooltips.html#Anchor.class
class
(X3D version 4.0 draft<https://www.web3d.org/x3d4>) [class type NMTOKENS<https://www.web3d.org/x3d/content/X3dTooltips.html#NMTOKENS> #IMPLIED<https://www.web3d.org/x3d/content/X3dTooltips.html#IMPLIED>]
The class attribute on each X3D node and statement is a space-separated list of classes, reserved for use by Cascading Style Sheets (CSS) and XML stylesheets.
Hint: this attribute is only functional if the X3D model is loaded within an HTML page.
Hint: X3D Architecture Annex L, HTML authoring guidelines, CSS considerations https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/Part01/htmlGuidelines.html#CSS
Hint: W3C Cascading Style Sheets https://www.w3.org/Style/CSS<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FStyle%2FCSS&data=04%7C01%7Cbrutzman%40nps.edu%7Cd668a006c34d4b3e440908d9860c2e79%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637688209779751819%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2BW7YUIxYdTa275ATgxgldLHGPJc3WSaZ8L%2BPzGNtDY0%3D&reserved=0>
Hint: CSS Snapshot https://www.w3.org/TR/css-2018<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2Fcss-2018&data=04%7C01%7Cbrutzman%40nps.edu%7Cd668a006c34d4b3e440908d9860c2e79%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637688209779751819%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=WhSeyCAIQs72oeh5b2Ih7wYtboCu1n44r2ISMw6JnDE%3D&reserved=0>
Hint: Wikibooks, XML - Managing Data Exchange/XSLT and Style Sheets https://en.wikibooks.org/wiki/XML_-_Managing_Data_Exchange/XSLT_and_Style_Sheets<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikibooks.org%2Fwiki%2FXML_-_Managing_Data_Exchange%2FXSLT_and_Style_Sheets&data=04%7C01%7Cbrutzman%40nps.edu%7Cd668a006c34d4b3e440908d9860c2e79%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637688209779761775%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=SA4UFUIelsj4M2OM06dMC4hDWKbPZkNcu%2FmT6oIKW10%3D&reserved=0>
* https://www.web3d.org/x3d/content/X3dTooltips.html#Anchor.id
id<https://www.web3d.org/x3d/content/X3dTooltips.html#Anchor.id>
(X3D version 4.0 draft<https://www.web3d.org/x3d4>) [id type NMTOKEN<https://www.web3d.org/x3d/content/X3dTooltips.html#NMTOKEN> #IMPLIED<https://www.web3d.org/x3d/content/X3dTooltips.html#IMPLIED>]
The id attribute on each X3D node and statement is considered a unique identifier when used as part of an encompassing HTML/DOM context.
Hint: this attribute is only functional if the X3D model is loaded within an HTML page.
Warning: the id attribute is in a distinct separate namespace from DEF identifiers and thus not applicable for USE nodes, ROUTE statements, or Script references.
Hint: X3D Architecture Annex L, HTML authoring guidelines, CSS considerations https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/Part01/htmlGuidelines.html#CSS
Hint: HTML5 id attribute https://www.w3.org/TR/dom41/#dom-element-id<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2Fdom41%2F%23dom-element-id&data=04%7C01%7Cbrutzman%40nps.edu%7Cd668a006c34d4b3e440908d9860c2e79%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637688209779771731%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=zrvXmwJpIlBVyqFblNsSEMjeR%2BbGGZm4kUThzKZwo4Y%3D&reserved=0>
* https://www.web3d.org/x3d/content/X3dTooltips.html#Anchor.style
style<https://www.web3d.org/x3d/content/X3dTooltips.html#Anchor.style>
(X3D version 4.0 draft<https://www.web3d.org/x3d4>) [style type CDATA<https://www.web3d.org/x3d/content/X3dTooltips.html#CDATA> #IMPLIED<https://www.web3d.org/x3d/content/X3dTooltips.html#IMPLIED>]
The style attribute on each X3D node and statement provides an inline block of CSS source for element styling, reserved for use by Cascading Style Sheets (CSS) and XML stylesheets.
Hint: this attribute is only functional if the X3D model is loaded within an HTML page.
Hint: X3D Architecture Annex L, HTML authoring guidelines, CSS considerations https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/Part01/htmlGuidelines.html#CSS
Hint: W3C Cascading Style Sheets https://www.w3.org/Style/CSS<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FStyle%2FCSS&data=04%7C01%7Cbrutzman%40nps.edu%7Cd668a006c34d4b3e440908d9860c2e79%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637688209779771731%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=C47k2kwMP1ySggei5muzEzJcceOBFUDnEvFs9bF6m8A%3D&reserved=0>
Hint: CSS Snapshot https://www.w3.org/TR/css-2018<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2Fcss-2018&data=04%7C01%7Cbrutzman%40nps.edu%7Cd668a006c34d4b3e440908d9860c2e79%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637688209779781691%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=C6DwdIZY6MXVadA%2Bfiph5wWaeSTjyFlHRMkvdy%2BuP4w%3D&reserved=0>
Hint: https://www.w3.org/TR/css-style-attr<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2Fcss-style-attr&data=04%7C01%7Cbrutzman%40nps.edu%7Cd668a006c34d4b3e440908d9860c2e79%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637688209779781691%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=PVal8SIPmuep1btswRaqeQXJ96p3q7HX8BcWUqKROYM%3D&reserved=0>
Hint: Wikibooks, XML - Managing Data Exchange/XSLT and Style Sheets https://en.wikibooks.org/wiki/XML_-_Managing_Data_Exchange/XSLT_and_Style_Sheets<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikibooks.org%2Fwiki%2FXML_-_Managing_Data_Exchange%2FXSLT_and_Style_Sheets&data=04%7C01%7Cbrutzman%40nps.edu%7Cd668a006c34d4b3e440908d9860c2e79%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637688209779791646%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=rk4qOoZxxcQDw34JfnRuhKCRnn9DPWHV%2BO3hbxopIAs%3D&reserved=0>
We can schedule this topic for X3D Working Group discussion in an upcoming weekly teleconference if you like.
Thanks (as always) for considering the issues. Sorry to interrupt more urgent issues, like the X3D-glTF paper and your other work. We should probably push this email thread to x3d-public (if OK with you) so that others can follow the trail of logic if desired. Take care Michalis.
all the best, Don
--
Don Brutzman Naval Postgraduate School, Code USW/Br brutzman at nps.edu<mailto:brutzman at nps.edu>
Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149
X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman
From: Michalis Kamburelis<mailto:michalis.kambi at gmail.com>
Sent: Saturday, October 2, 2021 10:59 AM
To: Brutzman, Donald (Don) (CIV)<mailto:brutzman at nps.edu>
Subject: Re: view3dscene and X3D4: attributes id, class and style
The reason why I'm asking "what to do with these XML attributes" is
that I don't consider "just ignoring them" a good solution.
The author put the attributes in X3D file, assuming that they have
some effect. Someone wrote """<Text style="color: #ff0000" />"""
thinking that it turns the text red -- but it does not, the "style"
attribute doesn't do anything, at least not in CGE/view3dscene.
(Disclaimer: this was just an example, I don't know if using such
style to change X3D text color works anywhere, even in X3DOM.)
So I'd much prefer to keep warning users about these attributes. Just
as we do now. These attributes don't cause any errors, everything else
works. But we display warning about these attributes -- because we
don't do anything with them. It is better to warn authors about the
fact that we don't handle them at all. If you generate X3D files that
are supposed to be displayed outside of DOM, you should remove them --
as they do not do anything when model is outside of DOM.
Until we have a clear specification that says when to allow these
attributes, on what (or all) XML elements, whether they are part of
X3D content (thus, exist independently of X3D encoding) or not, what
happens in classic encoding (or can we just forget this information),
what should be done when X3D content is not part of DOM... I don't
feel we should do more. Using these attributes in an X3D browser that
*does not* place X3D stuff in DOM deserves a warning.
Regards,
Michalis
wt., 28 wrz 2021 o 18:10 Brutzman, Donald (Don) (CIV)
<brutzman at nps.edu<mailto:brutzman at nps.edu>> napisał(a):
>
> Sorry to stir the pot prematurely, just wanted to let you know current status.
>
>
>
> I checked this morning and X3DUOM added the attributes to all XML elements for X3D.
>
>
>
> Support is provided in XML, Java, Python, Turtle in order to support experimentation using Annex L HTML Guidelines without any blocking errors occurring.
>
>
> No functional support requested of any X3D player. My original suggestion was to simply ignore them.
>
>
>
> Not trying to solve or confuse or convince anyone else of anything at this point, we have other tasks at hand. We are focused on editorial X3D mantis issues and Web3D 2021 preparations.
>
>
>
> Let’s move this to public when the time comes. Thanks Michalis.
>
>
>
> all the best, Don
> --
> Don Brutzman Naval Postgraduate School, Code USW/Br brutzman at nps.edu<mailto:brutzman at nps.edu>
> Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149
> X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman
>
>
>
> From: Michalis Kamburelis
> Sent: Tuesday, September 28, 2021 6:45 AM
> To: Brutzman, Donald (Don) (CIV)
> Subject: Re: view3dscene and X3D4: attributes id, class and style
>
>
>
> After reading "Annex L" it is not clear to me what to do with these
> fields, when you
>
> - read a separate X3D file (i.e. X3D is *not* part of HTML DOM),
> - want to preserve the data as part of X3D content,
> - convert between encodings.
>
> There are 2 options, both have some downsides, and they seem to
> conflict with each other:
>
> 1. If we want to allow to preserve this data, across encodings (XML,
> classic) then these should be just SFString fields of X3DNode. I mean
> instead of "Annex L", they should be part of X3DNode in "7.3.5
> X3DNode" https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/Part01/components/core.html#X3DNode
> like
>
> SFString id [] ""
> SFString class [] ""
> SFString style [] ""
>
> That is simplest for X3D browsers. Their definition in X3D would
> essentially say "these are for HTML DOM integration, you can ignore
> them if your X3D is not part of HTML DOM".
>
> The downside is that they make things a bit confusing. X3D authors
> may think that "id" is useful -- but it is useful only when X3D is in
> HTML DOM. When X3D is a separate file, not maintained as part of DOM,
> then a browser (even a web-based JS X3D browser) doesn't do anything
> with them I guess.
>
> 2. If we want to allow these attributes at all XML nodes (so, X3D
> nodes and X3D statements), when X3D is part of HTML DOM, then there's
> no easy place to record them for an X3D browser that doesn't keep X3D
> inside DOM. They are part of DOM, and not of X3D content described
> throughout "Part 1: Architecture and base components".
>
> This seems to be more in-line with what "Annex L" is saying. But
> it means there's no (easy) place to preserve this data, esp. as we
> cannot express this data in classic encoding.
>
> IMHO it also means that standalone X3D XML files should just not
> include these id, class, style. They are not part of X3D content, if
> we cannot preserve them across encodings.
>
> This would imply that an X3D browser that is *not* putting X3D
> inside HTML DOM should just ignore these fields. Or maybe they should
> not be allowed in separate X3D XML files at all. These fields only
> make sense when X3D is inside HTML DOM.
>
> I think 2 is better, and it seems more consistent with "Annex L". But
> it means that the only thing that view3dscene can do with these fields
> is
>
> - don't allow them (this is what we do now)
>
> - completely ignore them (this is similar to what we do now, we'd just
> remove the warning that they are not recognized -- nothing more).
>
> Note that this is independent of whether the X3D viewer runs as
> standalone program or in the browser. A JavaScript viewer that just
> reads X3D files (without integrating X3D in DOM) will have the same
> problem here -- id, class, style are not something that can be used
> for anything. The "Annex L" should probably make this distinction.
> It's not about "web browsers vs non-web browsers", it's about "X3D
> browsers that keep X3D inside DOM vs the ones that keep X3D in custom
> data structures".
>
> Regards,
> Michalis
>
> wt., 28 wrz 2021 o 06:37 Brutzman, Donald (Don) (CIV)
> <brutzman at nps.edu<mailto:brutzman at nps.edu>> napisał(a):
> >
> > Since they are called out in X3D4 Annex L HTML authoring guidelines these attributes are now allowed in the XML Schema and DTD, also supported in X3DUOM and Java/Python/Turtle. This enables authors to design X3D models for use with HTML without complaint.
> >
> >
> >
> > I think it is currently on just X3DNode though a case might be made for X3D Statements as well. Type is xs:NMTOKEN or xs:string matching HTML.
> >
> >
> >
> > Please use latest X3D spec version as your go-to reference:
> >
> >
> >
> > https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/Part01/Architecture.html
> >
> >
> >
> > I would suggest supporting it for ClassicVRML encoding to maximize interoperability in all directions. We will address that formally when we revise the X3D XML and ClassicVRML specifications.
> >
> >
> >
> > Postel’s Law: Robustness Principle
> > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FRobustness_principle&data=04%7C01%7Cbrutzman%40nps.edu%7Cdebe3c013f684cd1452a08d985ce474a%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637687943729479106%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=6h0o%2B0AH%2B4LsPBKuSEIdQ1U0AantrzDMImC7hTaLRm4%3D&reserved=0<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FRobustness_principle&data=04%7C01%7Cbrutzman%40nps.edu%7Cd668a006c34d4b3e440908d9860c2e79%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637688209779801601%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2BeLpvUTGfii%2BH8%2Fx7EL3vBa%2BGuE29heKKP%2BNrYrIl%2BI%3D&reserved=0>
> > "be conservative in what you send, be liberal in what you accept"
> >
> >
> >
> > all the best, Don
> > --
> > Don Brutzman Naval Postgraduate School, Code USW/Br brutzman at nps.edu<mailto:brutzman at nps.edu>
> > Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149
> > X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman
> >
> >
> >
> > From: Michalis Kamburelis
> > Sent: Monday, September 27, 2021 4:05 PM
> > To: Brutzman, Donald (Don) (CIV)
> > Subject: Re: view3dscene and X3D4: attributes id, class and style
> >
> >
> >
> > NPS WARNING: *external sender* verify before acting.
> >
> >
> > Of course, I can add it. Can you point me to the specification for it?
> >
> > I do not see id, class, style listed in
> > https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD3/Part01/components/core.html#X3DNode
> > .
> >
> > I want to make sure where is it included (for all nodes, X3DNode? just
> > WorldInfo?). I guess type is SFString. What should be done when these
> > nodes are not part of HTML DOM, e.g. are just present in a standalone
> > X3D file, that is handled only by an X3D viewer? Are they just
> > ignored? Are they expected to be preserved when converting to classic
> > and back to XML encodings?
> >
> > Regards,
> > Michalis
> >
> > wt., 28 wrz 2021 o 00:18 Brutzman, Donald (Don) (CIV)
> > <brutzman at nps.edu<mailto:brutzman at nps.edu>> napisał(a):
> >
> >
> >
> > >
> > > Hi Michalis, hope you are well. Thanks for your many efforts.
> > >
> > >
> > >
> > > FYI we’ve added attributes id class and style to the validation of X3D nodes, supporting HTML5 integration.
> > >
> > >
> > >
> > > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fx3dgraphics.com%2Fexamples%2FX3dForAdvancedModeling%2FHelloWorldScenes%2FHelloWorldX3D4Index.html&data=04%7C01%7Cbrutzman%40nps.edu%7Cdebe3c013f684cd1452a08d985ce474a%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637687943729479106%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ueRUx1JI9qa%2F8NGKcJuRlm1062iQXrYcYrGfbp2VnhU%3D&reserved=0<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fx3dgraphics.com%2Fexamples%2FX3dForAdvancedModeling%2FHelloWorldScenes%2FHelloWorldX3D4Index.html&data=04%7C01%7Cbrutzman%40nps.edu%7Cd668a006c34d4b3e440908d9860c2e79%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637688209779801601%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=PikHokGKIiFRkp%2BsVEolLGRDSFSKnQZqvldGIN5DGeo%3D&reserved=0>
> > > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fx3dgraphics.com%2Fexamples%2FX3dForAdvancedModeling%2FHelloWorldScenes%2FHelloWorldX3D4.x3d&data=04%7C01%7Cbrutzman%40nps.edu%7Cdebe3c013f684cd1452a08d985ce474a%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637687943729479106%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3vVdIBYWNZTTstFd9UDUfGFnkG6n9MTsf0befN9YiYA%3D&reserved=0<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fx3dgraphics.com%2Fexamples%2FX3dForAdvancedModeling%2FHelloWorldScenes%2FHelloWorldX3D4.x3d&data=04%7C01%7Cbrutzman%40nps.edu%7Cd668a006c34d4b3e440908d9860c2e79%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637688209779811558%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=mTtPxc%2BuRTEmbEmwq9g6GsCU9y59L5hWvYAT4kXREmE%3D&reserved=0>
> > >
> > >
> > >
> > > all the best, Don
> > > --
> > > Don Brutzman Naval Postgraduate School, Code USW/Br brutzman at nps.edu<mailto:brutzman at nps.edu>
> > > Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149
> > > X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman
> > >
> > >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20211003/d0695219/attachment-0001.html>
More information about the x3d-public
mailing list