[x3d-public] id attribute proposal; putting prose on pages
Don Brutzman
brutzman at nps.edu
Thu Apr 7 15:22:43 PDT 2016
Yes there is certainly lots to consider - thanks for your continuing and very thoughtful analysis Andreas.
Have been thinking not only about these many points, but also how our working group can proceed and progress effectively through the decision space.
- putting prose on page can help organize our thinking
- if image and attachment support on the wiki is indeed fixed, maybe that is the place.
- maybe we should even start a spec page... matter of when, not if.
- probably should work on wiki to collect and organize thoughts/questions/options/pros/cons first, rather than premature polarization of dueling-approach web pages.
We worked hard on other topics this week during Wednesday teleconference - to good effect - but didn't have time to explore "next steps" for ID, CSS, DOM activities.
Hopefully the starting-points above can help us begin to get organized and online effectively as a group working on X3D 4.0.
Thanks for the continuing thoughts and efforts.
p.s. old-fashioned writing technique: if procrastination, writer's block or analysis paralysis sets in, a simple remedy is "Put words on paper (WOP)" because it is easier to edit than to write... I guess now in emerging 21st century that notion is better expressed as Prose on Pages (POP). 8)
On 3/30/2016 1:47 PM, Andreas Plesch wrote:
> On Tue, Mar 29, 2016 at 11:43 PM, Don Brutzman <brutzman at nps.edu <mailto:brutzman at nps.edu>> wrote:
>
> An interesting relevant example in HTML4/HTML5 is the evolution of the Anchor tag <a>.
>
> In HTML4.01, both name and id attributes are allowed.
>
> ======================================================
>
> https://www.w3.org/TR/html4/struct/links.html#h-12.2.1
> 12.2.1 Syntax of anchor names
>
> An anchor name is the value of either the name or id attribute when used in the context of anchors. Anchor names must observe the following rules:
>
> Uniqueness: Anchor names must be unique within a document. Anchor names that differ only in case may not appear in the same document.
> String matching: Comparisons between fragment identifiers and anchor names must be done by exact (case-sensitive) match.
>
> Thus, the following example is correct with respect to string matching and must be considered a match by user agents:
>
> <P><A href="#xxx">...</A>
> ...more document...
> <P><A name="xxx">...</A>
> ======================================================
>
> Looking in HTML5 specification, the "name" attribute is not mentioned. Further it is quite difficult to find where a URL bookmark ending in #bookmarkName is defined for the anchor tag - there is a lot of dense prose, but still haven't found where it is specified.
>
>
> Yes, "name" is not used anymore (except for forms, I believe).
>
> Here is where URL syntax is defined:
> https://url.spec.whatwg.org/#url-syntax
> http://tools.ietf.org/html/rfc3986#section-3.5
> It allows "#" followed by a fragment identifier.
>
> https://www.w3.org/TR/html5/dom.html#the-id-attribute
> has a note that id can be used as a fragment identifier. It is not much to go by. Perhaps the DOM spec. has more on this.
>
>
> ...
>
> Looking over all of the interesting information which is being collected, carefully keeping DEF and id as separate but intertwined/correlated concept definitions might have a number of advantages.
>
>
> Yes, this is certainly an option especially if complete backward compatibility is high on the list of requirements.
>
> At this point it is beginning to seem like the following design goals might be defined and met:
>
> - Coexistence: DEF/USE syntax and semantics remain perfectly OK for ROUTE and Script usage within an X3D scene graph that itself is a DOM fragment.
>
>
> ok for route usage. It is rather difficult to reconcile how X3D scripts could coexist with DOM scripts in a DOM tree where a X3D scene is a DOM fragment.
>
> - Independence: The unique id attribute allows external HTML scripts up in the document DOM to operate independently of any internal X3D activity.
>
>
> The id attribute is actually not necessary to allow external scripts to operate on x3d nodes. As soon as a x3d scene becomes a DOM fragment and part of the DOM tree, each x3d node becomes a DOM element and can be accessed or created, even without an id attribute. So there is potential for cross-over of external manipulation and internal x3d activity. For example, it is possible to change a field by ROUTE internally and in parallel change the same field by external access. Perhaps it possible to avoid addressing this potential by delegating it to authors' and browser implementations' responsibility.
>
> - Integration: Conceivably, fallback rules for correlating id/DEF might allow for graceful integration: loading a legacy X3D v3 scene into DOM doesn't require authors to perform intentional addition of duplicative id attributes before passing events.
>
>
> Yes, this is what x3dom's mapDEFtoID option for inline accomplishes. However, x3dom's default mapping is DOM centric and does not assign an identical ID attribute since it assumes that the ID may be used elsewhere, outside the scene. This assumption may be overly cautious.
>
> - Separation: once an event is within an X3D scene graph, X3D semantics apply.
>
>
> Yes, DOM X3D browser implementations need to apply X3D semantics to interpret events. A complete separation of event handling seems difficult, since the DOM houses the x3d scene and can thus take over essentially anything if it so wishes.
>
> Not sure the X3DOM rules do that precisely, but they might be adapted to support these goals of coexistence, independence and integration.
>
>
> It sounds like the X3D centric mapping rules would best support these goals.
>
> For example, perhaps additions might state things like:
> - The DOM requires that all id values are unique.
> - If a DOM event is passed from the DOM to an X3D scene that does not have a matching target id attribute, then the matching DEF attribute identifies the target node instead.
>
>
> Or perhaps give each x3d node with a DEF attribute, an identical id attribute in the first place, even if only implied, in order to avoid entanglement with events.
>
> - A DOM event cannot be passed from the DOM to an X3D scene fragment that does not have a matching id or DEF attribute; it is ignored.
>
>
> yes. This may not have to be spelled out since the DOM would not be able to get a reference to a x3d node by using a non existing id value.
>
> - An X3D event can be passed within the X3D scene graph or externally to the DOM, if no matching X3D DEF is present and a matching id is found.
>
>
> hm. This means mapping id to DEF while also mapping DEF to id (see above). Not sure.
>
> - For identical (internal) DEF and (likely external) id names, the DEF name takes precedence when routing X3D events.
>
>
> Ok. This is the case where there is a DEF name which is also used by an external id. It may be best to not allow this, eg. leaving the behaviour undefined in case x3d centric rules are used. I was asking for example apps which do this but did get anything back. Probably need to check all x3dom examples but I do not think there is one which would do that.
>
> Encouraging design progress and dialog so far... examples and alternatives certainly help inform our understanding. To further increase clarity, we might build specific examples to illustrate each potential rule.
>
>
> Examples are good. Should we have a place to collect such examples ?
>
> Nevertheless we still have a ways to go, several tricky issues are still open:
>
> - How are SVG and MathML included and integrated within DOM?
>
>
> https://developer.mozilla.org/en-US/docs/Web/SVG
> https://developer.mozilla.org/en-US/docs/SVG_In_HTML_Introduction
> https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model#SVG_interfaces
> A SVG element is a DOM element. As such svg elements can be manipulated using the DOM API.
> SVG has animation through an animate element which can modify parent attributes, in a way similar to ROUTEs. I could not find a specification on what is supposed to happen if an animate element modifies an attribute internally while the same attribute is also modified by the DOM externally. I suspect behaviour is left undefined eg. there is some kind of fight going on.
>
> x3dom is partially inspired by SVG. The FHG publications have more on its DOM integration, I expect.
>
> https://www.w3.org/TR/MathML2/chapter8.html
>
> has the DOM part of the spec. which is actually then here https://www.w3.org/TR/MathML2/appendixd.html
>
> Interestingly, the latest spec. MathML3
>
> https://www.w3.org/TR/2014/REC-MathML3-20140410/
> https://www.w3.org/TR/2014/REC-MathML3-20140410/chapter6.html
>
> does not have a DOM spec. anymore. Perhaps it was never used since it is rare that you would want to animate, or programmatically construct math equations.
>
> BTW, should we start to use MathML in the x3d spec. for equations ? Currently, x3d equations seem to be hand-crafted by HTML font styling.
>
> - How are HTML5 scripts and canvas objects integrated within DOM?
>
>
> By HTML5 scripts, I assume you refer to the HTML5 script element ? It is a regular DOM element. It is actually quite common to create and access a script element (set the src attribute) from another script in order to inject/import functionality into a page.
>
> Canvas is a regular DOM element. In fact, you need to use the DOM to populate a canvas element with graphical content. As such, the canvas element has many DOM methods specific to it. The canvas element has no internal animation capability. Animation needs to be driven by external DOM access creating frames. This is what x3dom does. Canvas access, manipulation and rendering is very efficient in modern web browsers.
>
> - Need to list and illustrate all event-passing techniques from an external DOM tree into an X3D fragment.
>
>
> There is .setAttribute . x3dom has additional techniques: http://doc.x3dom.org/tutorials/basics/fields/
> What other events need to be passed ?
>
> - Determine whether the X3D fragment needs a separate namespace, or can adequately be referenced via simple xpath expressions.
>
>
> Could you expand ? With the json encoding it will be easy to put two x3d scenes on the same page, in a single DOM tree.
>
> - Determine whether the embedded "X3D namespaces" such as DEF/USE within a prototype or inline be unique, or ignored, or have specific prefixes.
>
>
> It should be possible to rely on the existing IMPORT/EXPORT semantics for DEF/USE. It could be adopted for ID as well, for simplicity. x3dom will keep the namespacename option which is more staightforward. Do we need IDs in a prototype ? Is it currently possible via SAI to access specific nodes in a specific prototype instance ?
>
> One more observation: isn't it interesting how a relatively "easy" id attribute proposal leads in all these many directions! 8)
>
>
> Oh yes. Let's be very focussed on keeping it to as few directions as possible (but as many as absolutely necessary).
>
> Andreas
>
> On 3/23/2016 8:00 PM, Andreas Plesch wrote:
>
> ad a.
>
> Statements such as ROUTE cannot have DEF fields, right ? What other potential DOM elements cannot have a DEF field ?
> Are these accessible by the SAI ?
>
> ad c.
>
> Although I cannot speak for Behr et al., I believe the x3dom rules meant to make it possible to separate x3d naming from DOM naming and keep x3d naming from interfering with DOM naming outside of x3d if so desired.
>
> I think, in practice this desire almost never materializes since the point of x3dom is to integrate x3d into the DOM. So the rule most often has the effect that it becomes necessary to assign DEF and id identical values.
>
> Andreas
>
> On Mar 20, 2016 11:53 PM, "Andreas Plesch" <andreasplesch at gmail.com <mailto:andreasplesch at gmail.com> <mailto:andreasplesch at gmail.com <mailto:andreasplesch at gmail.com>>> wrote:
>
> a.
>
> It may work to just declare in the spec. that the DEF value becomes the value of the id attribute when the node is interpreted as a DOM element. This way it may not be required to add an explicit id field to each node. However, it does seem narrow minded if simply adding an id attribute invalidates a x3d file.
>
> b.
>
> The default value for an explicit id field if deemed required could be the value of the DEF of the node.
>
> c.
>
> x3dom has both id and DEF attributes.
> If both id and DEF are set both attributes will have different values.
> If only DEF is given id is unset.
> If only id is given DEF and id will be set.
> http://examples.x3dom.org/example/x3dom_defUse.xhtml
>
> In addition, to allow working with valid x3d files, x3dom has an attribute for inline nodes MapDEFtoID which generates the ID value from the DEF value.
>
> d.
>
> Cobweb does not use the DOM for x3d.
>
> id is important for DOM compatibility and needs to be addressed in some way if x3d nodes are to be integrated in the DOM. If not, there needs to be clarification as well that x3d is not intended to be compatible with DOM use which would be a missed opportunity in my view.
>
> Before we think about class we need to deal with id I think.
>
>
>
> On 3/20/2016 2:33 PM, Don Brutzman wrote:
>
> Obvious questions:
>
> a. can DEF/USE simply be utilized instead? First law of engineering: "if it isn't broken, don't fix it."
>
> b. if DEF/USE cannot or ought not to be utilized, then how is is backwards compatibility handled? This includes Inline content loaded into a parent scene.
>
> c. what does X3DOM currently do?
>
> d. what does Cobweb currently do?
>
>
> On 3/20/2016 10:09 AM, John Carlson wrote:
>
> I'll second the proposal. Also I'd like to propose adding CSS selectors for values of the fromNode and toNode attributes on ROUTEs if not already in the standard. Thus if you have a node with id="foo" you could use a route with toNode="#foo". Class attributes would work similarly for fan in fan out.
>
> John
>
> On Mar 20, 2016 11:23 AM, "Andreas Plesch" <andreasplesch at gmail.com <mailto:andreasplesch at gmail.com> <mailto:andreasplesch at gmail.com <mailto:andreasplesch at gmail.com>> <mailto:andreasplesch at gmail.com <mailto:andreasplesch at gmail.com> <mailto:andreasplesch at gmail.com <mailto:andreasplesch at gmail.com>>>> wrote:
>
> Since Don mentioned that nobody has proposed introducing an 'id' attribute, let me then propose adding an 'id' SFString attribute to all nodes for x3d 4.0.
>
> The reason is simply compatibility with the DOM on web pages in the case where x3d nodes are interpreted as DOM elements.
>
> Andreas
> [...]
>
>
> 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 <tel:%2B1.831.656.2149>
> X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman
>
>
>
>
> --
> Andreas Plesch
> 39 Barbara Rd.
> Waltham, MA 02453
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
More information about the x3d-public
mailing list