stevedlawrence commented on issue #1200: URL: https://github.com/apache/daffodil-vscode/issues/1200#issuecomment-2734294262
> Should all of the dfdl:attributes listed in these sections be presented as suggestions for dfdl:element? Should the suggestions be narrowed down based on (simple) or (complex)? They should have the same suggestions as the XSD tag they annotate (e.g., xs:element, xs:simpleType), the only difference is that a dfdl:element/dfdl:simple/etc. should not suggest attributes with a `dfdl:` prefix. Note that a dfdl:element can only annotate an xs:element, dfdl:simpleType can only annotate an xs:simpleType, etc. For dfdl:element (and xs:element), those suggestions should be limited to only what is valid for a complex or simple element. So if you are trying to autocomplete a `dfdl:` tag, the logical should really be 1) find the tag that it annotates by looking at the parents 2) find everything that you would suggest for that tag 3) use those suggestions, but without the `dfdl:` prefix. > If so, how is simple or complex determined? Based on xs:element, xs:simple, or xs:complexType? This is where things get a bit tricky, since there are a number of things to check to determine this. If the `type` attribute exists on the xs:element, then you need to resolve the attribute value to a global xs:complexType or xs:simpleType that has the same name attribute value. Note that a type could also reference a XSD primitive, which are all simple types. If the `ref` attribute exists, then you need to resolve the attribute value to a global xs:element that has the same `name` attribute, and then you repeat these same checks on the resolves global xs:element to determine if that is simple or complex. If neither `type` nor `ref` exists, then you need to look at the children, and one of the children should be an `xs:complexType` or an `xs:simpelType` which signifies it's simple vs complex. Note that resolving type and ref to a global elements/types can be difficult, since that potentially requires looking at imports/includes inspecting global elements in other files. And there's a bunch of rules related to namespaces and includes/imports. The question is if all that is worth it. To do it 100% correct essentially requires parsing all schema file and includes imports. It's not easy. You might try to come up with some less complex solution that works for the common cases, and just falls back to suggestion all simple + complex properties if you can't figure it out. For example, checking if `type` is an XSD primitive is more straightforward, and tells you it's a simple type. > Appendix G separates dfdl:attributes by parsing or unparsing, from an intellisense perspective is it correct that the parsing and unparsing dfdl attributes would be suggested for the same element? Or is there some way to determine an element is defined for parsing or unparsing? You should suggest both parsing and unparsing. There really isnt a concept of "these elements are only for parsing or unparsing". There are some tricks to make it so some elements are only used for parsing vs unparse, but from an intellisense perspective that's not worth thinking about. > Should dfdl:sequence, dfdl:choice, and dfdl:group be suggested for xs:group? `dfdl:foo` should only be suggested for `xs:foo`, so only dfd:group should be suggested. > From an intellisense perspective does that mean intellisense suggestions should only include dfdl:length after the dfdl:lengthKind attribute with a value of explicit is added? This would require parsing each attribute and its value in a tag to determine which attributes to add to the suggestion list. Possibly. As you suggest, what you might want to do is determine if dfdl:lengthKind="explicit" and if so only suggest dfdl:length and dfdl:lengthUnits. Or if dfdl:lengthKind="implicit" then only suggest dfdl:lengthUnits". That said, figuring out the value of dfdl:lengthKind is tricky. It's not as simple as just looking at what attributes are defined for the current element. To do it 100% correct, you need to look at elements or types that if references with `ref` and `type`, dfdl:format, etc. The rules to find the in-scope property value is not trivial. So like mentioned above, you might try for just the low hanging fruit. E.g. only look at the current element you are auto completing. If it defines lengthKind, then you only suggested the appropriate attributes for that lengthKind. If it's not defined then just suggest all length properties. Or, just keep it simple and suggest everything. > Should all dfdl:attributes be suggested for the dfdl:format? Most of them. Things like dfdl:inputValueCalc and dfdl:outputValueCalc are not allowed in dfdl:format, as well as a handful of others. I don't think there is a list of properties that are not allowed in the spec that I can find, but I think they all say `It is not possible to place this property in scope on a dfdl:format annotation.` in their descriptions. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
