dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [dita] Some rambling thoughts about the domains attribute
- From: "Robert D Anderson" <robander@us.ibm.com>
- To: Bob Thomas <bob.thomas@tagsmiths.com>
- Date: Wed, 4 Jan 2017 16:01:54 -0600
Read the analysis in its entirety - I'm impressed. And thanks for the feedback - it all sounds correct to me.
> Now, when it comes time to
> interoperate, the names that were dictated by 2.6.3.7 mean entirely
> different things.
Exactly. 5 people could come up with 5 constraints that all use the token
(topic hi-d basic-HighlightingDomain-c)
Those constraints could all limit the highlighting domains in different ways. Alternatively, 5 companies could come up with exactly the same constraint, and all use a different token - such as a variant of
(topic hi-d companyName-HighlightingDomain-c)
> I don't believe that we could come up with a token-based
> grammar for @domains that would solve these problems.
Agreed - to be meaningful and unique, any token language that expressive would have to be as expressive as the constraint modules themselves.
Bob Thomas ---01/04/2017 03:24:10 PM---Despite the warnings, I went ahead and read the analysis in its entirety. I am left with the followi
From: Bob Thomas <bob.thomas@tagsmiths.com>
To: Robert D Anderson/Rochester/IBM@IBMUS
Cc: OASIS DITA TC List <dita@lists.oasis-open.org>
Date: 01/04/2017 03:24 PM
Subject: Re: [dita] Some rambling thoughts about the domains attribute
Sent by: <dita@lists.oasis-open.org>
Despite the warnings, I went ahead and read the analysis in its entirety. I am left with the following impressions:- The domains attribute is a metalanguage that attempts to describe which types and instances of shared vocabulary components are present in a shell
- The metalanguage is an insufficient foundation for fully implementing many of its use cases
- The "build it and they will come" philosophy behind some of the uses cases has yet to happen
My interest in this topic is primarily with respect to constraints. Not only does @domains fail to provide enough information, it can also be ambiguous. Consider this example from spec section 2.6.3.7 DTD: Coding requirements for constraint modules:
@domain value (topic hi-d basic-HighlightingDomain-c) is associated with this content-model fragment: <!ENTITY % HighlightingDomain-c-ph "b | i" >. But, who is to say that in the land of limitless interchange, there isn't some other Information Architect who has decided that the content-model fragment is this: <!ENTITY % HighlightingDomain-c-ph "sub | sup" >. Now, when it comes time to interoperate, the names that were dictated by 2.6.3.7 mean entirely different things. This deficiency means that the current @domain naming conventions for constraints are insufficient. At best, they say that constraints have been applied and things may or may not work. I don't believe that we could come up with a token-based grammar for @domains that would solve these problems. Given that, why have any constraint tokens at all?
Best Regards,
Bob Thomas
Tagsmiths, LLC
On Wed, Jan 4, 2017 at 10:24 AM, Robert D Anderson <robander@us.ibm.com> wrote:Over time I've come to see less and less benefit + more and more pain from the domains attribute. (Not from domains themselves - repeat, not from domains themselves - just the tokens in that attribute). I think they stand out as one of those DITA things with high level of complexity, little actual benefit, and (outside of attribute domains) few or no repercussions if you mess it up.
I started writing out all the arguments I've heard in favor of the attribute, and why I think most of them are no longer reasonable. Eventually I ended up with a small book. It's way too much for an email thread, so I've posted the resulting thoughts on a blog, and am curious what people think:
http://metadita.org/toolkit/nonononodomains.html
Warning, you may want to fill up on coffee before taking a look.
--
Bob Thomas
+1 720 201 8260
Skype: bob.thomas.colorado
Instant messaging: Gmail chat (bob.thomas@tagsmiths.com) or Skype
Time zone: Mountain (GMT-7)
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]