Optional attributes may have default values, required attributes may not. Why not?
Optional attributes may have default values, required attributes may not. Why not?
That is a good question! What an excellent feature that would be! I have had many, many use cases for this functionality and in fact, it was one of the original driving forces behind my Structure Tools plugin:
This plugin provides a wide array of default and auto-populate options. But I am not sure why a plugin is required... seems like it would be a simple thing to provide basic default value functionality within the core product.
Sorry, Russ, but I disagree. If there is a default value, the user is not required to specify a value. Thus, an attribute with a default value cannot be required, just by the definition of the English word "required".
It certainly may happen that some users (for example, those at a particular organization) of a widely-used tagging scheme may prefer to have a default for an attribute that is required by the broader tagging scheme. In such cases, the EDD can define a default and XSLT can fill in that value when switching between FrameMaker and XML.
If an attribute is required AND has a default value defined, doesn’t this then become an inherent property of the element and therefore does not need to be there at all? Sounds like data waste to me …
However, if other values can be defined as well:
E.g. a given “p” element (paragraph) could have a “dir” (direction) attribute, which could have the values “LTR” or “RTL”. The default value is defined in the standard as “LTR”.
It is not necessary to define dir=LTR for every p, as it is assumed to be an inherent property and any rendering engine is expected to assume this as the processing default and render the text from left to right.
It only needs to be declared if one of the alternative values (e.g. RTL) is necessary.
So, my take on that is: An attribute can be required *and* have a default value defined. In this case, it does not (and in my opinion should not) be added to an element. It should only be added if one of the alternate attribute values is needed.
However, I see that in certain scenarios it might be still necessary: Think of conreffing a p that is inside a Topic B (which has dir=RTL defined in the root (and therefore inherits this property)) in a Topic A which is LTR by default. Sure an engine should get that right (by parsing the parent elements for DIR in Topic B before inserting it in Topic A – and then … automatically add it?). But as this can make it very complex and drive down performance while it is probably a rare use case, the explicit declaration might still make sense.
I think maybe I am starting to agree with Lynne, which makes me disagree with myself . Maybe we could go a long time debating the language, but also maybe there is no compelling use case for a required attribute with a default value. I thought I ran into it before, but I might have been thinking of something else related to attribute values. Native FM features with regard to attribute management are very weak overall, so I may have my complaints mixed. Thanks for the input.
Good discussion, everyone.
Stefan, your direction example hints at the distinction between a required concept and a required attribute. Software may well support LTR and RTL languages and all text must use one or the other--that is all text inherently has a direction and users need a way of specifying what that is. How the user specifies the direction is a different matter than what the direction is. An attribute can be used for the purpose. If there is a default value, the user is not required to specify a value for the attribute, but the text still has a direction.
Even if there is no default value, the attribute need not be required. For example, the direction may be inherited from containing elements. Such a situation motivated impliable attributes in SGML and then XML, in which the default value is specified as #IMPLIED. #IMPLIED is described as covering cases where the processing application determines what value to use when no value is specified. SGML/XML does not distinguish such situations from those in which an attribute is not relevant unless a value is specified. For example, suppose the value of an attribute named Background names the background color used to format the associated element. When the attribute is not set, no background color is required. A different model might use a special value such as "None" to indicate that there is no background color, but some designers prefer that a color-related attribute be set only when a color is needed.
But for a moment back to the original question:
An attribute like “id” might be required for an element must must not have a default value for obvious reasons (as an ID usualy has to be unique).
Here is an example of a simple list:
Two attributes are given:
At the moment, both attributes are marked as optional.
But both attributes are required. And in the daily work default values are very helpful.
Therefore, elements with required attributes and default values would be on my wishlist.
Back in 1994 when I first discovered the delights of SGML, I too was puzzled by this rule, but eventually its reasoning became very clear. There really is a definite logical consistency with the idea that a required attribute cannot have a default value. The reason is that it's a requirement for the user to make a choice regarding the content of the attribute. By its very definition it cannot be a defaulted value because that means no choice has been made. It seems that the original question could be restated as "Why can't we have an attribute be required but also optional?"
I think it would be a real error to go down that path. This is really a fundamental SGML/XML rule that FrameMaker should stick with. Imagine how complex life would become if there was such a fundamental difference between XML and FrameMaker... (Yes there are already too many ).
Is your simple list example a real document? I've can't remember seeing the list type defined at the list item level before, it means that it must be defined for each new list entry. Wouldn't it be better placed on the <List> element?
Why would the 'StartWith1' attribute benefit from being required? The majority of the entries in a list will be 'False'. So if anything it should be an Optional attribute with a default of 'False'. Take the argument a little further and it would be easy to state that depending on the structure model, there would be no need for a 'StartAt1' attribute as it can be inferred from the structure.
I do not understand your example. You say you have two required attributes that are marked as optional. Do you mean that the EDD defines the attributes as optional but the documents are invalid unless values are specified?
By the way, are you working entirely in FrameMaker or are you using XML also?
Here are two scenarios in which an attribute is required at one stage of processing and optional at another. Does either of them fit your situation?
1. An organization is using FrameMaker to edit XML documents. Valid XML documents must be delivered at the end of the project. The original XML definitions have required attributes for frequently used elements. The documents may contain thousands of list items, and specifying required attributes for all of them is tedious. Furthermore, there are values that this particular organization could use as defaults which would significantly reduce editing effort. A solution is to make the attributes optional with a default in FrameMaker. When the documents are saved as XML, use XSLT to add values for these attributes when no values are specified, using the FrameMaker default as the generated value.
2. Required attributes affect the formatting of an element. To allow authors to create elements and content before providing attribute values, when no value is specified for the attribute, the EDD formats the elements as though some default had been specified. The documents are hence invalid, but has a reasonable format that makes the content easy to review.
Remember also that FrameMaker allows a user to assign the same value to an attribute of sibling elements in one operation. In your example, a List has numerous ListEntryLev1 elements, each of which sets Type to Ordered. Note that you can insert all the ListEntryLev1 elements without bothering to set the attribute. You can then select all the ListEntryLev1 elements by 1) double-clicking in the Structure Vew to the right of the child line that descends from the bubble for the List element or by 2) using the shortcut Esc h S. When all the ListEntryLev1 elements are selected, setting an attribute value applies to all the selected elements.
I agree with you completely about not changing the meaning of required attributes as defined in the SGML standard, approved in 1986.
Your second point, about specifying the Type on the entire list rather than on individual entries also make sense, but is a separate issue than that of default values for required attributes. There are other design changes that might make the structure easier to edit. For example, the name StartWith1 suggests that that attribute only applies to the first entry (the starting entry) in the list, so it could also be moved from the entries to the list. And if all lists reset the counter, the attribute isn't needed at all. Also, the element tag ListEntryLev1 suggests the possibility of nested Lists. Lothar hasn't shown how they are structured. When I define a nested list structure, I allow List to be a subelement of the item element--in this case, I would permit List as a subelement of ListEntryLev1 permitted after BodyText. And then I could use ListEntry for the list items regardless of whether they are in a first, second, or more deeply nested lists.
I'm working entirely in FrameMaker. The structure under discussion is a very old structure. I don't know, who was the responsible structure designer. Currently I'm a writer. I'm only using the given structures. Maybe this will change in the future. Therefore I would like to understand some elementary structural concepts, like the attributes.
That's how I understand the terms required and optional right now:
In the example above, however, a value is always required for the optional attribute StartWith1. So if the author is lazy and does not specify a value for the optional attribute StartWith1, then the default value has to do the author's work.
One of the first things I've read about SGML was: "SGML is a somewhat sophisticated language. Therefore, god created XML.". Perhaps XML is a little bit sophisticated, too.
The original design concepts of SGML included many features that were designed to make the hand-crafting of SGML content as simple as possible. One of the ways to achieve that was to provide ways to minimise the quantity of markup that had to be included. That's why an optional attribute with a default value does not even need to be present in the content. You are letting the parser work out what is intended. Also consider that the designer of an SGML application was expected to know how to design the structure for the minimum effort for the writer, which of course made that developer's work more complex.
So always think of the terms required and optional to be primarily aimed at the author's view of a document and its intended use, that was the original intention of SGML. XML evolved from SGML but with the emphasis on making the developer's job easier. This was probably due to the availability of mark-up aware editing tools. Some of those SGML features were now less important. Some 'nice' SGML features such as tag minimisation, inclusions and exclusions were were dropped to make the developer's life easier. Some features were so esoteric that I've never even seen them used and nobody missed them.
To address your points:
Thank you for clarifying your role in your structured FrameMaker project. Knowing that you do not currently have an XML requirement and that you are currently a user but not a designer/developer of your organization's structure will help us reply to your posts from the appropriate perspective.
As you no doubt gathered from some of the comments that have been made, some of us would have designed the structure you are using differently. If you ever take on designer tasks and update your element and attribute definitions, I'm sure this forum can support an active discussion on suggestions for change! Also, many of us are independent consultants who might be able to make some changes for you.
As Ian has said the terms "required" and "optional" refer to whether the writer is required to specify a value for an attribute. Your own post pointed out that if the designer didn't feel he was required to make an attribute available to the writer, he wouldn't have bothered to define it. In that sense, all attributes are required. Since there is no distinction, there's no need to mention the designer's view.