This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
2.2.2 states "Implementations must support DOM Core..." and lists Document as one of the required interfaces; the Document interface defines the following methods: createNodeIterator createRange createTreeWalker which return NodeIterator, Range, TreeWalker therefore, by transitive closure, these three types are also dependencies that should be listed in 2.2.2, that is, unless the support for Document is qualified to allow exclusion of these methods in a compliant implementation (thereby breaking the dependency)
Why would you need to mention the implicit dependencies explicitly? Then you might as well copy the whole specification. "Ooh, Node depends on implementing clodeNode which depends on the clone algorithm, which depends on... Lets copy all!"
(In reply to comment #1) > Why would you need to mention the implicit dependencies explicitly? Then you > might as well copy the whole specification. > > "Ooh, Node depends on implementing clodeNode which depends on the clone > algorithm, which depends on... Lets copy all!" because determining whether an implementation is compliant or not means knowing what interfaces are mandatory or not; as defined, it is ambiguous what is mandatory in an HTML5 UA; are these three interfaces mandatory or not? including Document as mandatory would seem to imply they are, but then they are not listed in 2.2.2 which makes one question the former
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: If we were to explicitly list the transitive closure of all the dependencies, we'd end up referencing specs like the electrical grid, screws, motherboard design specs, wifi... That way lies madness. If a reader wants to follow the references, they can follow them.
(In reply to comment #3) > EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are > satisfied with this response, please change the state of this bug to CLOSED. If > you have additional information and would like the editor to reconsider, please > reopen this bug. If you would like to escalate the issue to the full HTML > Working Group, please add the TrackerRequest keyword to this bug, and suggest > title and text for the tracker issue; or you may create a tracker issue > yourself, if you are able to do so. For more details, see this document: > http://dev.w3.org/html5/decision-policy/decision-policy.html > > Status: Rejected > Change Description: no spec change > Rationale: If we were to explicitly list the transitive closure of all the > dependencies, we'd end up referencing specs like the electrical grid, screws, > motherboard design specs, wifi... That way lies madness. > > If a reader wants to follow the references, they can follow them. in that case, please add a general comment in 2.2.2 that indicates the intention not to list type dependencies that obtain solely from indirect inclusion via transitive closure
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: I don't even know what that means; I cannot tell what problem it fixes, or what readers could possibly be confused by not having such a statement.