I donât think thereâs a conflict.
If we look only at document instances, then it should not be required that @specializations be present on the root element if its value is an empty string (specializations=ââ).
For documents that use attribute defaulting (i.e., all documents governed by normal DITA DTS or RNGs), the @specialization attribute should be declared but should not be required, i.e., it should have a default of #IMPLIED:
Robertâs first bullet just says the attribute must always be declared so any documents validated by the grammar will be valid if @specializations is present. Iâm saying that such documents should also be grammar-valid if @specialization is not specified.
I was trying to think if there was a way to reliably detect if @base and @props specializations are present but not declared on @specializations and the only thing I can think of is that any attribute not in a namespace and not defined in the base DITA spec *should* be either a @base or @props specialization and therefore any such attribute not specified in @specializations is probably an error. So it would be appropriate for processors to report such attributes but it should be at most a warning.
E.
Do we have a conflict between Eliot's comment and the first bullet point in Robert's comments?
I agree with Robert that the use of @specializations is implicitly required by the attribute domain facility, so not clear if it's useful or necessary to make a normative statement as long as it's clear that the *only* way a conforming DITA processor can know about an attribute specialization is via a @specializations value.
Note that when I refer to "document instance" I don't mean the xml data as written to disk, I mean the XML document *as parsed*.
That is, an attribute whose value is provided through a grammar file is "in the instance" when the document is parsed with respect to that grammar. If the document is not parsed with respect to a grammar that provides a default for the attribute then it must exist in the XML source.
DITA rules for documents are for the documents *as parsed*, so the question of *how* an attribute is supplied (literally in the markup or via grammar defaulting) is irrelevant as far as the normative rules about documents are concerned.
So we don't need to say anything about any requirements that any attributes be or not be declared--that's a syntax detail that is of no concern to the normative rules.
The rule is "if a document uses attribute domains those domains must be named in a @specializations attribute on the root map or topic element."
That makes it implicit that @specializations should not be specified if there are no attribute domains but it doesn't say it explicitly.
I think I agree that we shouldn't *require it* when there are no attribute domains but it might be useful to explicitly say that it is not required when the value would be empty.
Cheers,
E.
--
Eliot Kimber
http://contrext.com
ïOn 6/10/21, 12:19 PM, "Robert Anderson" <dita@lists.oasis-open.org on behalf of robert.dan.anderson@oracle.com> wrote:
ÂÂÂ Following up on our rules for the specializations attribute...
ÂÂÂ As Kris noted in the meeting this week, we already state that every attribute domain MUST provide a token for the specializations attribute. I think that covers a lot of what we need. Ideally, we can rely on that to avoid extra overlapping normative rules.
ÂÂÂ Beyond that rule, there are several places we might talk about the attribute:
ÂÂÂ * When defining a topic or map specialization, the grammar module for that topic or map really should define @spcializations as a valid attribute. I don't think we need a normative rule here; if so, it cannot be MUST because there are edge cases where
ÂÂÂÂ it's not relevant. I'd recommend a non-normative note though, that without this attribute, it will not be possible to integrate specialized attributes in a way that DITA processors will recognize.
ÂÂÂ * When configuring a document-type-shell, the shell needs to declare which specialized attributes are included. I don't think this is a normative MUST thing so much as "this is just a rule for setting it up" -- without doing it, things won't work. The
ÂÂÂÂ shell configuration sections already describe how to assemble those mandatory tokens from each attribute domain.
ÂÂÂ * We should take care talking about document instances, because this attribute is almost never set within a document instance. Instead, it is picked up from default values in the grammar file. It is valid for that default value to be empty (no specialized
ÂÂÂÂ attributes in use). It is also possible that someone specializes a topic or map without this attribute, in which case the document instance cannot set a value or pick up a default. In both of those cases, no attributes in the document would be recognized as
ÂÂÂÂ valid attribute specializations.
ÂÂÂ I'm less certain about where to include each of the items above (it's hard to agree on a location without a shared draft copy that we can all reference).
ÂÂÂ Thanks,
ÂÂÂ Robert
ÂÂÂ ________________________________________
ÂÂÂ From: dita@lists.oasis-open.org <dita@lists.oasis-open.org> on behalf of Kristen James Eberlein <kris@eberleinconsulting.com>
ÂÂÂ Sent: Tuesday, June 8, 2021 9:34 AM
ÂÂÂ To: DITA TC <dita@lists.oasis-open.org>
ÂÂÂ Subject: [External] : [dita] Normative rule about @class and @specializations required on the root element of every topic and map
ÂÂÂ Hi, folk.
ÂÂÂ The draft DITA 2.0 spec currently has the following normative rule:
ÂÂÂ "The root element of every topic and map MUST declare the following attributes:
ÂÂÂ * @class
ÂÂÂ * @specializations"
ÂÂÂ As part of the review of the proposal for "Relaxing specialization rules", we've had some commentary around this:
ÂÂÂ * Robert Anderson
ÂÂÂÂ"If a topic has no integrated attribute domains in 2.0, the value of @specializations will be empty. Is this really a
ÂÂÂ MUST? Should we clarify to indicate that this must be declared in the grammar, but does not necessarily need to have a value - I know that has caused confusion in the past for a tool that reported errors for empty @domains."
ÂÂ Â* Eliot Kimber
ÂÂÂ "If @specializations is only relevant to attribute specializations then I think it would be sensible to allow it to be omitted, with an omitted @specializations being equivalent to specializations="" (empty or whitespace-only value).
 ÂÂThe counter to that approach is that you can't easily distinguish between really having no attribute specializations and just forgetting to provide @specializations, but in that case I think you'd get runtime failures if you actually had specializations
ÂÂÂÂ that weren't declared (i.e., your @props specializations aren't recognized so things don't filter correctly).
ÂÂÂ Seems like an edge case in practice since DITA defines a number of out-of-the box attribute specializations, including now all of the original conditional attributes"
ÂÂÂ * Kris Eberlein
ÂÂÂ "We need to remove this normative rule from this topic. With the exception of specifying the @specializations attribute, it duplicates the normative statement that follows.
ÂÂÂ What do we want to say about the @specialization attribute and where?"
ÂÂÂ --
ÂÂÂÂBest,
ÂÂÂ Kris
ÂÂÂ Kristen James Eberlein
ÂÂÂ Chair, OASIS DITA Technical Committee
ÂÂÂ OASIS Distinguished Contributor
ÂÂÂ Principal consultant, Eberlein Consulting LLC
ÂÂÂ www.eberleinconsulting.com <https://urldefense.com/v3/__http://www.eberleinconsulting.com__;!!GqivPVa7Brio!LToLvAuQczxPWq2VL1XdgbWp2bvii-6J4jPbBigL1FnEPk0J5HwQ7ohZfe96wEK5oBkTCWE$>
ÂÂÂ +1 919 622-1501; kriseberlein (skype)
ÂÂÂ --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at:
ÂÂÂ https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php <https://urldefense.com/v3/__https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php__;!!GqivPVa7Brio!LToLvAuQczxPWq2VL1XdgbWp2bvii-6J4jPbBigL1FnEPk0J5HwQ7ohZfe96wEK5dAWAIhg$>
.
--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php