i'd like to create new elements, based on the link element. This would be more comfortable for the author than using the role and otherrole attributes to specify the link role.
Unfortunately the DITA-OT 2.2.1 fails with this message:
Required item type of result of template related-links:link.
is element(Q{}link); supplied value has item type
element(Q{}myelement)
Is this a valid approach, or should I stick to otherrole?
Update 1:
The error occurs in the related-links.xsl:
<!-- Ungrouped links have the default-mode
template applied to them. (Can be overridden.) -->
<xsl:template match="*[contains(#class, ' topic/link ')]"
mode="related-links:link"
name="related-links:link."
as="element(link)">
<xsl:sequence select="."/> <!--- error points to this line -->
</xsl:template>
This is clearly a bug in the XSLT implementation as you can't use direct tagname checks with any DITA processing because it will fail in the face of specialization as you're seeing.
Side note: assuming your specialization is a domain, the name for the domain should end in "-d" per the DITA naming conventions:
class="- topic/link mylink-d/mylinktype "
This is a convention not a hard requirement but it's useful to be able to look at the #class value and know if an element comes from a domain or a structural specialization.
Related
Does FIX protocol allow to reuse same tag in a message and in repeating groups? I.e. could I have something like that
<message name='Quote' msgtype='S' msgcat='app'>
<field name='Price' required='Y'/><!-- i.e. total price for the whole quote-->
...
<group name='NumLegs' required='Y'>
<field name='Price' required='Y'/><!-- i.e. leg price -->
...
<group name='NumLegDetails' required='Y'>
<field name='Price' required='Y'/><!-- i.e. leg component price -->
...
</group>
...
</group>
</message>
TL;DR
It is not allowed in the tag-value encoding.
(but in FIXML it is)
Some explanations
My initial misunderstanding came from this statement in the FIX tag-value specification: see here, search for "Field presence"
A tag (field) must appear at most once in a message, except when the
tag appears within a repeating group.
But as I learned this refers to the wire format of the message, not the definition of the message.
Whereas the FIX5.0SP2 spec Volume 1 refers to the definition of the message and states:
A tag number (field) should only appear in a message once. If it
appears more than once in the message it should be considered an error
with the specification document.
In the meantime I even found it mentioned in FIXimate when looking at the NestedParties component (emphasis mine): (link to NestedParties component in FIXimate)
The NestedParties component block is identical to the Parties Block.
It is used in other component blocks and repeating groups when nesting
will take place resulting in multiple occurrences of the Parties block
within a single FIX message.. Use of NestedParties under these
conditions avoids multiple references to the Parties block within the
same message which is not allowed in FIX tag/value syntax.
BTW, there are also components NestedParties2, NestedParties3, NestedParties4 to work around this.
Information from FIX Trading Community Forum
The thread can be accessed here, but as far as I know you can only access it if you are a FIX TC member: FIX TC forum
The FIX expert Hanno Klein gave the following information:
The quote from the refactored online spec refers to the wire format of
any instance of a message encoded in tagvalue syntax. It means that
inside the wire format of a single repeating group a tag (field) may
appear more than once.
FIXML does not have this restriction:
The restriction is actually limited to the tagvalue encoding. For
example, the parties component is “Pty” for all instances in FIXML,
the XML syntax/encoding of FIX. This is due to the fact that the XML
syntax has an unambiguous structure with a distinct path to every
occurrence of a component or field. The XML names only need to be
unique within the same element.
Tag-value does:
For tagvalue, a parser needs to know when a repeating group starts and
ends. The NoXXX field marks the starting point and a field that is not
part of the group marks the ending point. There are no explicit
delimiters for repeating groups in tagvalue and components
(non-repeating) are not visible in the wire format at all.
Technically, you are probably right that a Price tag could exist in
two distinct repeating groups without causing a parser issue but I do
not see the benefit to allow this exception to the rule. You cannot
allow it for two adjacent levels, e.g. root + nesting level 1 or
nesting level x + nesting level y.
This part from original answer still applies
On another note, when defining your own repeating groups please use the notation NoXXX for repeating groups since that is the official recommendation. see here, search for "NumInGroup field"
It is recommended that NumInGroup fields be named NoXXX, e.g.
NoContraBrokers(382).
However, following your example with 44/Price you would normally see 566/LegPrice used as the price for an individual leg since the two are used differently. The former is the price used for the execution of an order, the latter is used when defining a leg of a strategy.
So in short, when defining your message structure and repeating groups you should really think about if the meaning of the tag is the same for all occurrences of the tag in the message and if it really makes sense to use the very same tag in the body and in repeating groups. Clarity should be first priority.
incorrect (strike through) part of original answer
At first I thought that this could not be allowed but mainly because I have never seen it appear somewhere in a real message. But actually I could not find a reason why it should not be allowed. The specification only says: see here, search for "Field presence"
A tag (field) must appear at most once in a message, except when the
tag appears within a repeating group.
A tag (field) must appear at most once per repeating group instance.
No, this is not allowed. I suggest you get a large data dictionary from http://www.quickfixengine.org, save it to your computer in XML format, and then execute a command like the following:
grep Price FIX.xml | grep number
Doing that will show you the definitions of all the Price-related fields. If you search for each of those field names within messages/components, you will see that each one is used in a different place. The overall result is that each field is listed only once in a message.
You can't re-use a repeating group tag outside a repeating group.
The declaration of a tag as a repeating group tag puts constraints on it, such as its order within a group and how one occurrence is treated differently to a subsequent occurrence. Non-repeating group tags have no such constraint.
Setting the scene:
I'm working on a webapp in Eclipse, with a bunch of JSPs and XSLs. And I need to hide some features depending on some users' attributes. This is the third job in the series.
For the previous 2 jobs, I was able to achieve my goals because either the required changes were on JSPs (straightforward) or on XSLs for which the objects existed.
I.e. We have the following sequence:
- searchForm.jsp (a form with some criteria you set up and submit),
- resultsList.jsp (a list of search results - clicking on any result brings the full record for the result),
- displayItem.jsp (the full record),
- record.xsl (the xsl that transforms displayItem.jsp).
Thus for the 2 previous jobs, the features I needed to hide were either on these JSPs themselves or on the xsl, in which case the (relevant) JSPs had:
<c:set target="${item}" property="xsltParameter" value="xxxx=Y"/>
where 'item' is an existing object and 'xxxx' a (usually but not necessarily global) parameter defined in the xsl.
For example:
<xsl:param name="xxxx">N</xsl:param>
Thus, if my changes were on the xsl, I would reuse the 'item' object to pass on my parameter and process it in the XSL(s).
E.g. I'd put on the jsp:
<c:set target="${item}" property="xsltParameter" value="abcd=AAA"/>
and add to the xsl:
<xsl:param name="abcd"></xsl:param>
This way I was able to pass my own parameters to the xsl.
For this last job however:
- The XSL (filters.xsl) is quite short and self-contained.
- It appears on the same page as resultsList.jsp, (therefore after searchForm.jsp) but has no connection I can see with it.
- On the JSPs, there's NO (appropriate) target object I can (re)use.
- I've already tried on a/the JSP the way I know to create variables/parameters:
<c:set var="xyz" value="${abcd}"/>
but this doesn't seem to work (when I create a corresponding xyz global parameter in filters.xsl).
My issues are:
- I'm struggling to create an object (if that's what I need to do).
- I may need to do something else, but I'm not sure what (hence my post).
Plan B
In desperation, with plan B I'm creating as a proof-of-concept, a static xml file (param-val.xml), in the same location as the XSLs, in which I put my external parameter/criterion:
<paramroot>
<paramval>abcd</paramval>
</paramroot>
What I'd like to do is using the document() function, extract this parameter and use it either within filters.xsl if possible or otherwise a go-between prefilters.xsl that filters.xsl would import. And this is where I'd need some help/tips/etc.
<xsl:param name="theXML" select="'prefilters.xml'" />
<xsl:variable name="myDoc" select="document($theXML)" />
I've been reading stuff on the web and tested a few things, but I'm stuck (rusty on some topics and learning others). How can I grab and use the 'abcd' in either filters or prefilters?
Any suggestions on how best to handle this?
Sorry for the lenghty post. Any help would be greatly appreciated.
Many thanks and regards.
I have looked at the sample code for Karabiner where you can create a filter that applies to a window name, but I would like to apply the filter, when I am creating new emails. Since the window name changes, I would like to filter on the Application Bundle Identifier instead. Does someone have an XML example of filtering on Application Bundle Identifier?
The developer's manual provides both steps to determine the app bundle identifier as well as examples of usage. I have included one of my own below.
You must first determine if the app you're interested in is pre-defined by Karabiner. Check appdef.xml and search that page for your app's identifier.
If it wasn't found in the existing definitions, you will need to define a name for the application that you will use in <item> blocks later. (Neither of these are great examples, as they are both pre-defined in appdef.xml for use under WORD and GOOGLE_CHROME, respectively.)
<?xml version="1.0"?>
<root>
<appdef>
<appname>MWORD</appname>
<equal>com.microsoft.Word</equal>
</appdef>
<appdef>
<appname>CHROME</appname>
<equal>com.google.Chrome</equal>
</appdef>
Instead of using <equal>, which as the name implies only matches exact strings (including case), you can use <prefix> or <suffix> to match against the beginning or end of the app bundle identification string, respectively.
Once you've done this, when you're creating your item, you have a few options on filtering. First is to restrict to just that particular application, which I believe is your goal.
<item>
<identifier>private.fixscrollwheel</identifier>
<name>Always Rotate Scroll Wheel</name>
<only>CHROME</only>
<autogen>
__FlipScrollWheel__
Option::FLIPSCROLLWHEEL_ROTATE,
</autogen>
</item>
Note the <only> tag. This restricts the above item to only working with an app whose bundle identifier is com.google.Chrome, since that's what CHROME corresponds to in the <appdef> tag at the top.
You can define multiple applications to be matched by simply including more appnames in your <only> tag, such as this:
<only>CHROME, MWORD, MAIL</only>
You can also do the inverse, i.e. all applications except those listed, by changing <only> to <not>.
I'm working on a custom GNAT GPS plugin (for GPS 6.1.2).
My plugin XML creates a project attribute "example_list_of_files".
This is a list of strings, that correspond the names of Ada files in the project.
I want to default the entries in that list to "a.adb","b.adb","c.adb". However I've been unable to find the correct syntax for this. Instead i end up with a single string of all the values.
What i want to see is what happens when you manually add three elements, as shown below:
Here is the code for this example:
GPS.parse_xml('<?xml version="1.0" ?>' + """
<my_plugin>
<project_attribute
name="example_list_of_files"
label="example_list_of_files"
description="A description...."
package="MyPackage"
editor_page="MyPage"
editor_section="Build"
hide_in="wizard library_wizard"
omit_if_default="false"
list="true"
base_name_only="true">
<string type="file" filter="project" default="'a.adb','b.adb','c.adb' " />
</project_attribute>
</my_plugin>""");
Notice the string element with the project attribute default. Instead of a list of entries in the project manager it gives me a single entry, containing the string "'a.adb', 'b.adb', 'c.adb'".
Anyone got any ideas? I've also tried multiple string elements, adding brackets, braces, square-brackets, space separators, prefixing with 'array(' with no luck.
thanks
Matt
It seems indeed this is not supported. The standard plug-in projects.py has several list attributes, but all of them have a single value as the default. I'll check what can be done to improve here.
However, your approach might be wrong in the first place. The default you are setting only concerns the project editor. That means that if a user uses a default project (like project default is end default) and never goes through the project editor, your attribute example_list_of_files will in fact not exist (and have a default empty value). So it seems that this should in fact be handled in your plug-in, when you query the value of the attribute (like via GPS.Project.get_attribute_as_list). If that function returns an empty list, then use ("a.adb", "b.adb", "c.adb") instead. That way, things work fine even with a default, unedited project.
From the GPS User's Guide:
The tag accepts the following attributes:
[...]
list (boolean, default false)
If true, the project attribute contains a list of values, as opposed
to a single value. An example is the list of source directories in
standard projects.
In your example:
<string type="file" filter="project" default="'a.adb','b.adb','c.adb' " />
This is a single string value. Instead, you should specify a list of string values, like this:
<string type="file" filter="project" default="a.adb" />
<string type="file" filter="project" default="b.adb" />
<string type="file" filter="project" default="c.adb" />
Using as a reference: https://support.google.com/webmasters/answer/146750?hl=en
You will notice under 'Product' that there is a category Property, and furthermore there's an example on down the page:
<span itemprop="category" content="Hardware > Tools > Anvils">Anvils</span>
which I've mimic'd exactly:
<span itemprop="category" content="kitchen sinks > stainless steel sinks > undermount">undermount</span>
Yet when I test it with Google's structured data tool, I get the error:
Error: Page contains property "category" which is not part of the schema.
I realized in the example also, it's using data-vocabulary.org→Product, where I'm using schema.org→Product.
Now on http://schema.org/Product, it does not have category anywhere mentioned. Does schema.org not offer categories? Or am I missing something?
category is an itemprop of schema/Offer, not schema/Product
To fix your problem, place an offer within the product, and attach the category to the offer.
Note: You are using a content attribute on span, which is not valid in HTML5 or Microdata (but in RDFa).
Schema.org has a category property, but it can not be used on Product. Depending on your content, you may want to use Offer instead of Product (see also my answer with an example use of category).
I've been working on JSON-ld & microdata a lot recently, and I believe in your case 'category' needs to be placed in a meta tag, not span/div tag, preferably before your item. Logically, your need to identify 'undermount' is redundant as it would already be included within your content. Oddly, the schema type service has 'serviceType' as a property, but product does not have an equivalent, otherwise that could have been another workaround. For your content 'undermount' use itemprop="name" within your span, no content within that tag necessary.
<meta itemprop="category" content="Hardware > Tools > Anvils > Anvils" />
Here is the correct format accepted by schema.org...