Hiding a valid attribute from Attributes View

[dcramer]

I have a situation where I need certain attributes to be valid in my schema, but I do not want users to add this attribute manually or have them be confused the attributes cluttering up the Attributes View. Is there a way to configure my Document Type so that certain attributes do not appear in the Attributes View (and other places where it might be suggested, like content completion) even though they're valid according to the schema?

Thanks,
David

[sorin_carbunaru]

Hello David,

For this purpose you can use a content completion configuration file, about which you can read more at https://www.oxygenxml.com/doc/versions/ ... ually.html. In short, you have to edit (or maybe create) the OXYGEN_INSTALL_DIR/frameworks/YOUR_FRAMEWORK/resources/cc_config.xml file and add a line such as

Code: Select all

<elementProposals rejectAttributes="YOU_ATTRIBUTE_NAME" />

inside. This way you should be able to achieve what you desire.

All the best wishes,
Sorin Carbunaru
oXygen XML

[dcramer]

Ah, this looks like a very useful file. What I really want to do is the following to suppress these attributes on all elements in the docbook namespace:

Code: Select all

<elementProposals  xmlns:db="http://docbook.org/ns/docbook" 

                                path="db:*" 

                                rejectAttributes="db:idfixup db:idprefix db:linkscope" />

But "db:*" isn't allowed by the schema: "Value 'db:*' is not facet-valid with respect to pattern '([\i\c]+(\[.*\])*)+(/([\i\c]+(\[.*\])*))*' for type 'pathType'." Do I really need to repeat this element once for each element in DocBook?

[sorin_carbunaru]

Hello David,

It seems to me that even if the schema complains about the path, still oXygen rejects those attributes. I tried on my side with xlink:href. Please let me know if you get to the same conclusion.

On the other hand, you could probably just remove the path attribute, which means the customization will then apply to the proposals for all elements.

Sorin C.

[dcramer]

Unfortuantely, path="db:*" ends up being the same as omitting the path attribute and applies the rule to all elements.

My goal is to hide these attributes from elements in the DocBook namespace, but to allow them on the xi:include element. These attributes must be legal on all elements that can be included via xi:include (and I allow any element to be includable) because xinclude 1.1 passes these attributes down when it resolves the xincludes. But I don't want users to see these attributes anywhere in Oxygen since it makes no sense (and might do harm) if they add them to DocBook elements.

For now, I've made a list of DocBook elements from TDG and included them all as separate elementProposals in my cc_config.xml. Not idea, but it works for now.

Thanks,
David

[sorin_carbunaru]

Hi David,

Thank you for explaining the use case! It really is helpful. I will add an issue regarding the behavior of the path, and we will update this thread when we will solve the problem.

Sorin C.

[chrispitude]

Are cc_config.xml files incremental?

I've extended the DITA framework. In my <framework>/resources/ directory, I created the following cc_config.xml file to hide some DITA attributes:

Code: Select all

<?xml version="1.0" encoding="UTF-8"?>
<?xml-model href="http://www.oxygenxml.com/ns/ccfilter/config/ccConfigSchemaFilter.sch" type="application/xml" schematypens="http://purl.oclc.org/dsdl/schematron"?>
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.oxygenxml.com/ns/ccfilter/config http://www.oxygenxml.com/ns/ccfilter/config/ccConfigSchemaFilter.xsd"
    xmlns="http://www.oxygenxml.com/ns/ccfilter/config">

    <elementProposals path="*" rejectAttributes="audience base class deliveryTarget dir importance otherprops othertype outputclass platform rev snpsatt spectitle status translate xml:lang xtrc xtrf"/>

</config>

When my <framework>/resources/ path is at the top of the resources list, the attributes are hidden. When it's at the bottom of the list, they are not.

I'm happy it works when it's at the top of the list, but does that mean my simple cc_config.xml file is blocking the base DITA framework's cc_config.xml file from being applied?

[Radu]

Hi Chris,

The first cc_config file found in the classpath wins. So you will need to copy the base cc_config and use it as your own making your own changes to it.
I added issue with ID EXM-44610 to look into merging them although sometimes the current behavior is better if you want to overwrite completely certain behaviors.

Regards,
Radu

[chrispitude]

Thanks Radu! The ability to override is certainly a good one, and we wouldn't want to lose that ability.

But in the meantime, it would be nice to mention at

https://www.oxygenxml.com/doc/versions/ ... als__d2e47

https://www.oxygenxml.com/doc/versions/ ... lly__d2e47

that the first cc_config.xml file in the classpath list wins.

[chrispitude]

Hmm, I might have hit a more serious problem. When I hid the @class attribute, all my CSS customizations that use @class stopped working. I assumed that rejectAttributes would hide attributes from the Attributes view, but I didn't expect it to suppress them from the internal machinery inside Oxygen.

Is this expected behavior?

[Radu]

Hi Chris,

I found this older thread in a way by accident. Starting with Oxygen 23, you can place your configuration rules in a "cc_config_ext.xml" file which gets merged with the base "cc_config.xml".
I see I had not answered your last remark, indeed when you start hiding attributes like @class with the cc_config.xml, the attribute's default value will no longer be propagated in various places and I suspect this breaks things, fixing this would be quite problematic I'm afraid. We have Java API to ignore certain attributes just from being displayed but the cc_config is at a deeper level.

Regards,
Radu