Binding subcomp to child/ren
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 20/100
Hướng nghiên cứu
Bắt đầu với tài liệu example1 được liên kết và phần thảo luận trong issue 2 của org.lemsml.model, sau đó kiểm tra các điểm đầu vào của parser hoặc interpreter xử lý các phần tử XML Component và Child. Issue này cần một quy tắc rõ ràng, nhất quán cho việc binding các phần tử con trước khi có thể coi việc triển khai là hoàn tất.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
According to the docs, the shorthand notation for defining components consists in using ComponentType as the xml-element name instead of <Component type=...>:
[...] Once the units are available it is possible to define a component. There are two equivalent ways of doing this: either by using the Component element and setting its type, or by using the type as a new XML element [...]
In the same example, though, we find
<HHGate id="n" power="4">
<Forward type="HHExpLinearRate" rate="0.1per_ms" midpoint="-55mV" scale="10mV" />
<Reverse type="HHExpRate" rate="0.125per_ms" midpoint="-65mV" scale="-80mV" />
</HHGate>
Where <Forward> and <Reverse> are not Component Types (they even have a type attribute), but the name attribute of a Child definition in the ComponentType:
<ComponentType name="HHGate">
<Parameter name="power" dimension="none" />
<Child name="Forward" type="HHRate" />
<Child name="Reverse" type="HHRate" />
In this case, <HHGate> would have two <Child> of type HHRate, and the element name is being used to determine which is which.
One can always argue that <X name="aX"> is nicer to type than <Component type="X" name="aX">, but being able to bend the rules again and use <aX> (if and only if it is a <Child>) seems abusive to me. Consistence is not only good for us writing parsers/interpreters -- which will have a lot of ad-hoc checks to cope with those special cases -- but for users as well, as changing notation in "magic" places tends to be confusing and frustrating.
Keeping the discussion here in mind, I suggest (@robertcannon) to stick to the <X name="aX"> notation (even though I'd like to be radical on the consistency side and abolish the shorthand notation altogether...).
@pgleeson will probably say we have to live with it since it is used all around NeuroML2 - but actually, this seems to be the case (multiple <Child> with the same type) only for Gate opening / closing rates.
- Ngôn ngữ chính
- Java
- Star
- 13
- Fork
- 11
- Chỉ số merge pull request
- Không có pull request nào được merge trong 30 ngày
Chuẩn bị môi trường
Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của LEMS/jLEMS
-
bug
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 35/100
-
bug
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 45/100
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 45/100
-
bug
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 35/100
-
As a user I want to set a recording frequency different from the simulation/integration time stepĐang mởenhancement help required
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 38/100
Issue tương tự
-
bug follow-up lane:backlog
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
Sanne/incus-spawn#1576 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 69/100
checkstyle/checkstyle#22069 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 86/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 67/100
it-at-m/eNoVa-Editor#79 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
Maintainer thường phản hồi trong vòng 1 ngày