This sounds correct to me. The menus can always be clear by specifying the dfdl: prefix, but contextually when inserted that prefix would be omitted inside a DFDL element like dfdl:format, dfdl:element, dfdl:simpleType, etc.
Question: Does intellisense keep track of the default namespaces? (I probably tested this in the last RC, but I've forgotten.) We write schemas mostly now so that no "xs:" nor "xsd:" prefix is used. We always use "dfdl:" prefixes. We never make the DFDL namespace the default namespace, but we do make the XML Schema namespace be the default namespace most of the time now in our DFDL schemas. On Tue, Nov 19, 2024 at 8:51 AM Regis Thomas <regis.tho...@nteligen.com> wrote: > > I am working on the IntelliSense portion of the Daffodil VS Code extension. > Based on feedback. I learned that the dfdl namespace prefix, should not > appear with a dfdl attribute if the tag element contains the dfdl namespace. > > For example if the tag <dfdl:format contains any dfdl attributes, the dfdl > namespace should not appear with any of those attributes. > > In the current production code for IntelliSense, when a suggestion is > selected that contains a dfdl attribute, the IntelliSense code will always > write the dfdl namespace along with the dfdl attribute name when completing > the suggestion. > > The logic change I am making will leave off the dfdl namespace if the tag > where a suggestion is triggered contains a dfdl element with the dfdl > namespace prefix. > > I am testing this change against a varied selection of dfdl schemas. One of > the schemas is “edifact-sc-d038b.dfdl.xsd”. That schema has a number of > sections like the following: > > > > 67 <xsd:choice> > > 68 <xsd:element name="FunctionGroup" maxOccurs="unbounded"> > > 69 <xsd:complexType> > > 70 <xsd:sequence> > > 71 <xsd:element dfdl:ref="ibmEdiFmt:EDISegmentFormat" > dfdl:initiator="UNG" name="UNG" type="srv:UNG-GroupHeader"/> > > 72 <xsd:element ref="D03B:Message" maxOccurs="unbounded"/> > > 73 <xsd:element dfdl:ref="ibmEdiFmt:EDISegmentFormat" > dfdl:initiator="UNE" name="UNE" type="srv:UNE-GroupTrailer"/> > > 74 </xsd:sequence> > > 75 </xsd:complexType> > > 76 </xsd:element> > > 77 <xsd:element ref="D03B:Message" maxOccurs="unbounded"/> > > 78 </xsd:choice> > > > > Lines 71, 72, and 73 above, all have an xsd:element tag. I’m not sure how to > handle the dfdl:ref attribute with the namespace in line 71 and 73, and also > handle the ref attribute with no namespace in line 72. > > > > The Apache DFDL Specification has an example for dfdl:element that contains a > ref attribute. > > > > <xs:schema ...> > > ... > > <xs:element name="root"> > > <xs:annotation> > > <xs:appinfo source=http://www.ogf.org/dfdl/> > > > > <dfdl:element ref="aBaseConfig" > > representation="text" > > encoding="UTF-8"/> > > > > </xs:appinfo> > > </xs:annotation> > > </xs:element> > > ... > > </xs:schema> > > > > I am thinking about having the suggestion list always contain the dfdl > namespace with each dfdl attribute, and listing non dfdl attributes without > any namespace. For an element tag, intellisense would suggest both “ref’ and > “dfdl:ref”. If “dfdl:ref” was selected in the first code example, the dfdl > namespace prefix would be written along with the “ref” attribute since the > element tag does not have a dfdl namespace prefix. The user would have to > select the “ref” attribute without the dfdl namespace prefix from the > intellisense suggestions for line 71. > > > > In the second example (from the Apache DFDL Speicification) only the > “dfdl:ref” attribute would be shown, not the “ref” attribute in the list of > intellisense suggestions (along with any other applicable dfdl attributes). > If “dfdl:ref”is selected, the “dfdl” namespace prefix would be omitted since > the dfdl:element tag does contain the dfdl namespace. > > > > The “dfdl:ref” attribute seems to be the only dfdl attrtibute that would > require this special treatment. As far as I can tell there is no “dfdl:name” > attribute (which might require the same treatment). > > > > This solution addresses this problem, however similar logic is used to > provide hover definitions for the dfdl attributes. This solution would mean > that a hover definition for dfdl:ref would only occur, but no hover > definition for “ref” would appear. > > > > Is this the best approach to the “ref” vs “dfdl:ref” situation? > > > > Regis Thomas > > Nteligen, LLC > > 6716 Alexander Bell Drive, > > Suite 120 > > Columbia, MD 20146 > > (240) 864-5042 x126 > > regis.tho...@nteligen.com > >
