[W3C] [SVG] [CSS] XBL Issues List

  1. closed The task force has an open issue about the title of the document (i.e., "XBL Binding Language"). Mozilla has called it "Extensible Binding Language" (but XBL is not Extensible) and "XML Binding Language" (but choosing one of the technologies XBL uses arbitrarily for the name seems odd). Currently the "X" in "XBL" stands for "XBL". Some working group members do not think this is professional enough and that it is confusing.
    Hixie
    I propose we call the SVG version "sXBL (SVG XBL)", and the second version "XBL 2.0". This avoids confusion with Mozilla XBL. I'm fine with officially claiming that XBL stands for "XML Binding Language", although of course the real name is "XBL Binding Language".
    The spec has been updated to match the above proposal since there are no current objections.
  2. closed This issue was about where to store the source HTML and where to post the drafts. There is an agreement to store the source HTML on the SVG group's CVS system and to post drafts on the W3C site.
  3. closed The task force had an open issue about the ordering of the editor list. Ian had unilaterally decided on the ordering of the editor list, apparently feeling that the main criterion for ordering the editor list is to make sure that one particular editor is at the bottom, which is not a good way to win friends and influence people. Jon appeared to have decided the opposite. Both were using arbitrary arguments regarding logical orders ("alphabetical by last name", "alphabetical by full name", etc) to defend their positions. Ian decided he had bigger fish to fry and agreed to use Jon's arbitrary ordering (which puts Jon's name at the top, and XBL's original inventor's name at the bottom).
  4. closed The previous version's introductory sections contained language that was too CSS-specific. The introductory language has been updated.
  5. closed The previous version targeted both SVG and non-SVG scenarios, and feedback suggested that only the SVG scenario should be normative. The sXBL version explicitly states it only applies to SVG and that future versions may extend to other markup languages. The 2.0 version includes non-SVG material.
  6. closed The previous version included descriptions in section 1.0 that were too CSS-specific. The new wording is better, but some think it is clumsy. Awaiting proposed changes to the text.

    Jon: We need to look at the paragraph that talks about not redefining semantics of an element. It seems inappropriate and unnecessary for sXBL and might also be inappropriate and unnecessary for XBL 2.

    Closed.

  7. closed The task force is still undecided about whether the current tag names can be improved or whether they are acceptable.
    Hyatt
    Proposal
    Ian
    Proposal

    The current names are based on recent discussions, but do not represent consensus.

    Closed.

  8. closed The term "XBL subtree" below really doesn't help and probably confuses. This terminology isn't used in the Mozilla spec for XBL. It would be better to say something like "binding definitions". (But first review issue XBL-7, which wonders if the term "binding" itself is appropriate.) The heading that used this term has been changed; is it better now?

    Closed.

  9. closed RCC didn't have a notion of a new type of file with a new root element. RCC's <extensionDefs> and <elementDef> elements could be in an external file, but that external file was just another SVG file. We need to talk about this. It is important for SVG to know the type of files it is opening so that it apply appropriate semantics to the file. For example, if SVG opens an external foo.svg file which contains <svg:symbol> elements, it knows that it should apply CSS styling on that foo.svg file, which is a critical requirement for proper processing of the SVG <use> element. What should happen if an SVG UA encounters a foo.xbl file? Should it treat it as if it were an SVG file, and thus apply any stylesheets within <svg:style> elements and recognize and <?xml-stylesheet?> processing instructions? RESOLVED: we don't need external XBL only files.
  10. closed If there is a new file type foo.xbl that is defined by the W3C, do we need to define and register its MIME type, its windows suffix, its Mac four-letter Creator code, and whatever else happens? The SVG group probably doesn't want to take on this additional work in the SVG 1.2 timeframe. So far, the email discussion seems to say that we don't need to register the XBL MIME type, at least not right away, but everyone should have one more chance to object before classifying as CLOSED. This issue is moot since ISSUE 9 resolved that XBL 1.0 can only appear inside *.svg files.
  11. closed It seemed like "HTML" should be replaced by "XHTML" throughout. But a larger issue was whether XHTML/HTML should be mentioned at all in the first draft, or whether the first XBL spec should just restrict itself to being normative about SVG, and not mention anything about [X]HTML. All references to HTML have been removed from the 1.0 draft.
  12. open The terminology "relevant element" below is confusing, and the description below about "ignored" is a total head-scratcher. Nothing in RCC had this level of complexity, so under the assumption that all features to which this might apply are out of scope for SVG 1.2.

    Changed it to "correct element" and "is in error" - Ian

    Jon: Re-opened. Changing "relevant" to "correct" helps but doesn't address the fundamental complaint. Re-opened because various sections which use the word "correct" might be inappropriately written for a W3C spec and require more detailed review.

    ACTION JF: Send editorial comments on sXBL by Nov 5th.

  13. closed The previous version talked about the test suite being normative and included wording about errata and errata overriding the spec in an incorrect place within the document.
  14. closed The previous draft said that content and implementation must honor what's said in this specification, and feedback said that was unnecessary. The objectionable sentences were removed.
  15. closed In terms of what to do in the presence of non-conformant XBL subtrees, this might need to become a host language dependency. For SVG, the rule is that the UA should stop rendering at the first element which is in error (non-conformant) relative to the SVG specification. Given this rule and its major implications on how SVG UAs are built, it is necessary that the same rule apply when processing XBL. RESOLVED: XBL shall define a certain amount of error handling for all XBL implementations, and SVG will define additional error handling specific to XBL in the SVG context.

    Remaining issue: Exactly what should the error handling be? SVG working group to study current text and report.

    Closed.

  16. closed How much in the way of error handling rules should we have? There is an open issue about the use of the terms "Expected parent" and "Expected children". An argument is that W3C's XML languages are defined by DTDs or XML Schemas (or RelaxNG [:)], and these facilities indicate definitively what sort of a tree is valid and which is not. In the case of SVG, it is an error for an element to appear in a place not allowed by the DTD. For XBL embedded inside SVG, the XML Schema for SVG will indicate the places where XBL is allowed to be inserted. For the case where the XBL content is in a separate foo.xbl file (but see ISSUES 9 and 10, above), then the XBL Schema should have a complete definition of which elements can be children of which parent elements, plus appropriate ANY definitions to allow non-XBL content.

    There is a debate between the strict mindset of the SVG working group and the forgiving mindset from people on the XHTML+CSS side of the world. If so, then it might make sense to say that the host language must define error processing rules. However, this would require implementations to do the error handling twice, increasing the probability of errors.

    RESOLVED: XBL shall define a certain amount of error handling for all XBL implementations, and SVG will define additional error handling specific to XBL in the SVG context.

  17. closed How should tags be "implemented" by (that is, how should tags be bound to) bindings when not using the DOM nor CSS? The SVG group reached a consensus at its recent meeting that there should be a 'namespace' attribute on <xbl:xbl> and a 'name' attribute on <xbl:binding> just as exists now in the RCC drafts within the latest SVG 1.2 spec. However, this has been unfavourably reviewed by other members of the task force. Another solution has been proposed by Peter and Ian, and is currently specced in this draft.

    Closed.

  18. closed How should bindings be imported, if not via CSS or DOM? Recent email seems to be converging on <xbl:import> perhaps with an 'xlink:href' or 'href' attribute. import it is. XLink vs not-XLink issue has been moved to another issue
  19. open In the previous version, there was a proposal for a 'style' attribute that specifies the stylesheet language. There was feedback that there is no such attribute in the Mozilla XBL spec, that it was highly unintuitive to use a 'style' attribute in this manner when XHTML and SVG both have a 'style' attribute which contains CSS property declarations, and anyway, in both XHTML and SVG, the <style> element has a 'type' attribute which is #REQUIRED, so a default styling language parameter is unnecessary for these two host languages. There was a counter argument that no one uses the 'type' attribute, even though it is #REQUIRED.

    There has been some suggestions that instead of having one style language per binding, we should require UAs to support mixing style languages, and so require authors to repeat the style language on every style element. (This issue can be deferred to 2.0 if we decide scoped stylesheets are out. See 23.) The current draft now replaces the previous version's 'style' attribute with a 'style-type' attribute.

  20. open The 'selectors' attribute does not seem like the optimal way to construct the language. At a minimum, having the allowable syntax of an attribute change based on the setting of any other attribute precludes leveraging validators. It seems better to some to have a 'select' attribute that takes an XPath and thus mimics/reuses the same attribute name that XSLT uses for the same purpose. Regarding W3C Selectors to choose children, this is something that isn't needed for SVG 1.2. Regarding XPath to choose children, that is something that is deemed unimplementable in their target devices. Down the road, we could add another attribute suitable to choosing children via CSS selectors, such as 'css-selectors'. With SVG, the rule is that, if present, CSS takes precedence, so (down the road, after SVG 1.2) if 'css-selectors' and 'select' are both present, then if 'css-selectors' is present, it overrides 'select'.

    The includes-type attribute does not represent consensus within the task force. The task force is currently split on what language or language subset to use or require for the includes attribute. The current draft now replaces the previous version's 'selectors' attribute with a 'includes-type' attribute.

  21. closed The previous draft talked about the default UA stylesheet with an @namespace rule, which was criticized because CSS wasn't a requirement for XBL 1.0. The objection section was removed.
  22. closed This issue was about error handling rules in section 2.1 (in the description of the <xbl> element). Error handling is still an open issue. RESOLVED: XBL shall define a certain amount of error handling for all XBL implementations, and SVG will define additional error handling specific to XBL in the SVG context.
  23. closed What was the consensus regarding resources in the SVG 1.2 version of XBL? What was the consensus regarding resources after SVG 1.2? It seems like SVG 1.2 does not need or want to deal with scoped style sheets. Should scoped stylesheets be in the SVG version of this spec? If not, how are bindings styled? Two unresolved issues here: should XBL 1.0 include any resources features, and the large question about stylesheet scoping. Removed resources section from sXBL
  24. closed Was consensus reached on the event forwarding issue? It was a requirement for RCC to work within an SVG context. Here is a description of event forwarding: "Events that fire on a bound element are automatically dispatched by the user agent to corresponding event listeners that are registered on the corresponding <definition> element. For example, if a DOMActivate event is fired on the bound element, and if a DOMActivate event listener is registered on the corresponding <definition> element, then an additional DOMActivate event is dispatched to the <definition> element.

    Replaced events section with XML Events-compatible proposal.

    But further editorial cleanup is still necessary.

    Closed.

  25. closed The issue was: "Does the sentence in the description of the <definition> element make sense which talks about the <definition> element being a first element in a binding document? It seems like <definition> is always a child of <xbl>, and therefore never the first element." It has been resolved by removing the offending section.
  26. closed (Error handling issue again.) In the description of the <definition> element, the 'id' attribute here has a longer description that the 'id' attribute on the <xbl> element, which reflects unbalance and probably indicates the need for some editorial cleanup. But before cleaning up, why is the extra wording here relative to the 'id' attribute necessary or desirable? Certainly for SVG, there is already language in the SVG spec that talks about what to do with invalid attribute values. Since XBL doesn't ever stand alone, it seems like the error processing rules should be defined by the host language. (Similar approach to SMIL Animation.) Perhaps the XBL spec can say that host languages must define what happens when an invalid value is encountered. RESOLVED: XBL shall define a certain amount of error handling for all XBL implementations, and SVG will define additional error handling specific to XBL in the SVG context.
  27. closed (Follow on to ISSUE XBL-17) An issue was raised which suggests it might be better to have a 'elementName' attribute (as decided at the SVG FTF) on the <definition> element like RCC's <elementDef> than this draft's invention of an <xbl:bind> element. Used definition element="" per discussion
  28. closed Relative to the <template> element description referring to <xbl:inherits> and <xbl:pseudo> sub-element: SVG 1.2 does not support inheritance. The <xbl:pseudo> element seems like a good idea in order to allow all of those new pseudo elements and classes from CSS3 for XForms to reach into the shadow tree; however, SVG 1.2 isn't going to support these features from CSS3, so even if this is a great idea, it needs to be moved into a future considerations appendix. Reference to <xbl:inherits> and <xbl:pseudo> have been removed.
  29. closed (Tag naming issues again.) Perhaps it would be better if the element name were <contentTemplate> instead of just <content> since the shadow tree's resulting content often is changed dramatically versus what was in the original "anonymous content template". Resolved tag name is template
  30. closed In the description of <template>, you will see the words "if the conditions specified by the template are met". What conditions? In RCC, the prototype was copied over always, without conditions.

    The text "conditions" now hyperlinks to the definition of those conditions (basically, it's error handling). Is this now resolved along with the other error handling issues?

    Closed.

  31. closed In RCC, there were two distinct binding events: SVGBindBegin (which was raised upon reaching the begin tag of the bound element) and SVGBindEnd (upon reaching the end tag). Having separate events was a requirement for SVG, and the proposed reconciliation approach which the SVG group assembled at the recent FTF said that both of these events are a requirement. Regarding cloning the <template> element, in RCC this happens after reaching the bound element's end tag. The '***BindEnd' is raised right after the cloning. These editorial changes will be postponed to avoid editorial collision and therefore allows for further discussion.

    The spec has been updated with five events for key moments in the binding and unbinding process.

  32. closed 'applyAuthorSheets' is out of scope for SVG 1.2, but if we don't include it then we have to change the default for 2.0. Default was changed and attribute removed from sXBL.
  33. closed There was a criticism about a sentence at the end of section 2.3 which didn't make sense for SVG. The sentence was removed.
  34. open (See issue 20.) There is still an unresolved issue about how best to have the <xbl:content> element refer back to the bound element's children. RCC uses a 'select' attribute with an XPath expression. Mozilla XBL uses an 'includes' attribute with an XPath expression. The BECSS draft of XBL uses an 'includes' attribute with extended CSS selectors (i.e., extended beyond what is described in the CSS2 spec). The text below proposes that the 'includes' attribute changes its rules based on the 'selectors' attribute on the <xbl:xbl> element. See ISSUE XBL-20 above, which raises the 'selectors' approach as an ISSUE. No editorial changes at this time, but for the SVG 1.2 version of XBL, why not just do either what RCC does (an XSLT-compatible 'select' attribute) or what Mozilla XBL does (an 'includes' attribute that has an XPath expression). The ability to leverage CSS selectors isn't a requirement for SVG 1.2, so that feature belongs in the future considerations part of the spec. The current version uses the same approach as the previous version, except some minor renaming of attributes. Some would want a required subset of XPath.
  35. closed Issue about removing xbl:inherits from XBL 1.0 since SVG 1.2 will not support adding behaviors to element. xbl:inherits main value is with behaviors. xbl:inherits is no longer in the document.
  36. closed Issue about removing xbl:pseudo since SVG 1.2 will not support CSS3's new selector features, such as all of the XForms-related pseudo classes and pseudo elements. xbl:pseudo is no longer in the document.
  37. closed There is still an open issue about whether the first version of XBL should include any resource and prefetching facilities, such as 'style' and 'prefetch'. The SVG group does not want to have to support such XBL-defined features in SVG 1.2. 'resources' and 'style' are still present, but 'prefetch' has been removed from this version, so only remaining issue is a duplicate of the scoped stylesheets issue. Resolved. Scoping removed from sXBL.
  38. closed There was a question with regard to SVG 1.2's version of XBL. The SVG WG decided at its FTF that bindings could only be attached to non-SVG elements for SVG 1.2. The specification reflects this decision.
  39. closed The SVG WG only wants to bind via namespace/tagname matching for SVG 1.2. Therefore, no the 'binding' property. The 'binding' property has been removed from this version.
  40. closed At the SVG FTF, the decision was that when XBL was used by SVG, the SVG language's existing facilities for registering scripts and handlers would be used, and therefore there would not be an <xbl:handler> element. The handler section has been removed for sXBL.
  41. closed Attribute forwarding was an issue. RCC did not include this feature, so most likely the SVG working group will want to push this feature into a future version of XBL. The section on attribute forwarding was removed.
  42. closed The SVG WG decided that <xbl:element> will not be supported in SVG 1.2. The <xbl:element> element was removed.
  43. closed The SVG WG decided that <xbl:inherited> will not be supported in SVG 1.2. The <xbl:inherited> element was removed.
  44. closed There is still an open issue about stylesheet scoping rules. The SVG language has multiple features that already exist that depend on stylesheets being scoped to the entire document which references the stylesheet (where the stylesheet is referenced via an PI or a <svg:style> element). There was once apparent consensus that XBL 1.0 needs to support this approach, at least as a subset of the stylesheet scoping features that are supported, but then the CSS people began questioning the legitimacy of SVG's whole approach to style scoping. The open issue is whether we need to go beyond document-level scoping. From an SVG perspective (at least some members), scoping for stylesheets should either be defined by the CSS spec or the host language specs (e.g., the SVG spec), not by XBL, but obviously this view might not be universal, which means only do document-level scoping for XBL 1.0, which would be non-backwards compatible. Should stylesheets in the binding source document affect the anonymous content of bindings once they are in the bound document? Working on this.

    Closed.

  45. closed There is still an open issue regarding the new interface definitions. The writeup below is derivative of what was proposed for BECSS/XBL and therefore also derivative of Mozilla/XBL. This is quite a bit different than the DOM definitions for RCC. The task force needs to check that the RCC requirements with respect to the DOM interfaces are met.

    The interfaces have been simplified since the previous draft, but still reflect the original Mozilla interface definitions, which is different than what the SVG group defined for RCC. Are any RCC features missing?

    Closed.

  46. closed It seems like there is consensus that the ownerDocument for the binding definitions is the document which includes the binding definitions. The current draft ways: "All anonymous nodes' ownerDocument pointers are left pointing at the binding document."
  47. closed There has been a lot of discussion but the issue is still open about whether the 'parentNode' for the first level shadow content should be the bound element or NULL. If we want it to be the bound element, then some think we probably need to coordinate with the DOM group about whether they think this is OK. There was discussion, and and some flip-flopping of opinions, but no agreement yet.

    Closed.

  48. open Need to specify the implementation section better (constructor, destructor, examples)
  49. open The text says: "XBL is a mechanism for overriding the standard presentation and interactive behavior of particular elements with different presentation and interactive behavior." That makes it sound potentially harmful, like subverting the semantics. It doesn't cover the (common) case where there *is* no standard presentation or interactive behavior. It also seemingly excludes the case where XBL is used to *implement* the standard presentation (eg, a rendering of MathML). Need replacement text.

    Moved to XBL2.

  50. closed Need a history section.

    Closed.

  51. closed The draft at the moment uses "src" attributes for sourcing subresources. SVG uses "xlink:href". What should we use?

    Closed.

  52. progress Should XBL 2.0 use XML Events or roll its own? XML Events as is doesn't really fit XBL. There is a proposal for extending XML Events to get around the problems, which we are currently using.

    Moved to XBL2.

  53. closed Scoped getElementById() within a shadow tree. Should sXBL or XBL 2.0 include a scoped getElementById() facility for searching a particular shadow tree for an element which has a particular ID value?

    Closed.

  54. closed Binding/attachment event names. The current draft has five events, all in the http://www.w3.org/2004/xbl namespace: attaching, generating, attached, detaching, detached. Are these the event names (and corresponding definitions) that we want to use?

    Closed.

  55. closed Replace "Expected parent" and "Expected children" descriptions in the spec with XML Schema snippets?

    Closed.

  56. closed Allow arbitrary children for xbl:xbl, xbl:definition and xbl:template elements?
  57. open The XBL2 spec need to say anything about HTTP redirects.

    Moved to XBL2.

  58. closedFor the sXBL spec, does the Abstract need to provide more context so that the reader better understands the W3C's long-term direction with XBL?

    Chris has an action item for writing some more text about this.

    Closed.

  59. closedIt seems like we need a new section in both the sXBL and XBL2 specs that talk about the requirements for host language specifications which will allow XBL to be used in conjunction with that host language. One model is SMIL Animation's chapter: 5. Integrating SMIL Animation into a host language.
  60. closedWhat does the topology of the fully flattened view look like exactly? We haven't totally nailed the definition of what happens with the xbl*** entries (e.g., xblFirstChild, xblNextSibling) on NodeXBL under various scenarios. If we complete that definition, are we done? Maybe not. The fully flattened view currently shows the bound element, but in some scenarios the bound element is not "skipped" by the user agent, which means that in some (all?) cases you traverse and process the fully flattened tree as if the bound element were not there.

    Closed.

  61. openWhat do we do about XBL2 and the SVG requirement that elements have to be owned by a single document for the purposes of styling, ID resolution, timeline management, font names, ICC colors, device colors, etc.
  62. openIn XBL2, can styling (selectors and/or inheritance) cross the boundary from the bound element into the shadow tree?
  63. openIn XBL2, can styling (selectors and/or inheritance) cross the boundary from the binding back to the bound element and its descendants?
  64. closedIf the original 'xbl:template' element gets modified (not the clones that are attached to shadow trees), do all bindings that reference that 'xbl:template' get re-invoked?

    Closed.

  65. openShould XBL support a model where everything in the shadow DOM can be discarded by the user agent and regenerated as needed? For example, suppose you have zoomed in on an SVG file and a large part of the content is not in view. Should it be possible for the SVG user agent to implement an optimization in which shadow trees on some elements are temporarily discarded and then regenerated on demand when they come back in view?

    Moved to XBL2.

  66. closedWhat happens if an 'xbl:definition' does not include an 'xbl:template'? Does the binding still happen (e.g., are binding events raised)? If so, is the xblShadowTree have the value of "null"? If xblShadowTree is null, does the original bound element rendered, or is nothing rendered?
  67. openCan the 'binding' property have a value of 'inherit'? It would simplify implementation greatly if the 'binding' property were not allowed to have a value of 'inherit'. (In fact, it might be a requirement in order to allow for robust implementations.)
  68. openShould the XBL 2.0 implementation be designed so that it can be implemented separately from the host languages (e.g., HTML+CSS and SVG) or is it OK to specify XBL 2.0 such that it requires intermixing of code bases?
  69. open Now that the shadow content is no longer really inside the document, we need to carefully define exactly how STYLE elements, SCRIPT elements, XML Event elements, etc, act in shadow content: when it is applied, and when it is not applied. For example, <form> <div/> </form> where the <div>'s shadow tree contains an <input/> -- is it in the form? (when parentNode pointed to the bound element, the answer was clearly yes, since the form was a parent of the shadow content, but now it is no longer clear). What about if you bind an element like svg:switch, does it switch on its children or its shadow tree?

    Pending proposal from IH.

  70. closed Should there be an introductory section that introduces the main concepts (e.g., the attachment of a shadow tree) and gives an example? The SVG spec has an introductory section with an example for both the filters chapter and the animation chapter.

    At the SVG FTF meeting in Toronto May 26-28, the SVG WG proposed that the introduction should contain simple examples. In particular, the SVG WG decided that a simple "Hello world" level example was appropriate. In this draft, there is a "Hello world" example in the introduction and then the examples that existed in the most recent RCC spec have been included in an examples appendix. (With an issue to remind the group to review the examples appendix.)

    Resolved as such 2004-06-16.

  71. closedDo we want a temporary appendix (that is, only present for the short period between the first draft of sXBL and the Last Call of sXBL) that shows the mapping between RCC and sXBL?

    At the SVG FTF meeting in Toronto May 26-28, the SVG WG proposed that the first public draft of sXBL should include such a comparison table.

    Resolved that we want appendices to compare with RCC and XBL1.

  72. open The task force agreed that if the original binding document DOM is changed dynamically, bound elements using the affected bindings should be immediately affected, including having their templates regenerated if appropriate. Text needs to be written to specify this for XBL2.
  73. open

    Does the spec define whether svg:script, html:script, etc, blocks execute in parallel with document parsing and XBL processing or if it happens at some other point? We need to have it defined so that we have interop on how much of the document is visible to script, and how many bindings are accessible to script, when script blocks are executed.

    One important case to consider is a large file with a binding definition followed by a script block at the top that mutates the binding definition. If the binding applies to multiple elements in the large file, do they act as if they had the original binding applied until the document has completely loaded, or does the mutation happen straight away?

  74. closed Rename "insertion point" to "<content> element" or similar.
  75. open (XBL2 only) Make sure we define what happens if inherits="" forms a loop.
  76. closedVerify that the terms "binding document" and "binding source" are used correctly throughout.

    Closed.

  77. open (XBL2 only) Should there be a difference between explicit inheritance and implicit inheritance?
  78. closed Selectors/XPath: Need a note.
  79. closed Need to update the combinators stuff to reflect what we agreed about selectors not going through other scopes.
  80. closedVerify that the terms "shadow tree", "shadow content", and "template" are used correctly throughout.

    Closed.

  81. closedAt the Toronto FTF, the SVG WG discussed what happens if the reference doesn't find a valid target, such as if the referenced file doesn't exist? Note that the referenced file might not be available immediately but will be after a short wait (e.g., wait for the referenced file to be downloaded). What about externalResourcesRequired=true? The conclusion at the Toronto FTF was that the SVG specification already seems to address these issues completely.

    Closed.