RE: [dita] Groups - Proposal 12008 - vocabulary and integration constraints (HTML) (IssueConstraints12008.html) uploaded

["Tony Self" <tself@hyperwrite.com>]

So, Michael, in this example, the warning that "non-constrained" info was being used in a conref should appear in the editor?  I am trying to work out in this context whether "processor" means the transforming process to produce output, or the schema processor in the editor.

 

When the content is processed to output, constraints should have no impact. If the required shortdesc has already been enforced during the editing process, the output processor (which knows how to process shortdescs whether they are included or not) doesn't need to bother doing anything different.

 

Have I got this right?

 

Tony

---

From: Michael Priestley [mailto:mpriestl@ca.ibm.com]
Sent: Wednesday, 22 August 2007 11:13 PM
To: Eliot Kimber
Cc: dita@lists.oasis-open.org
Subject: RE: [dita] Groups - Proposal 12008 - vocabulary and integration constraints (HTML) (IssueConstraints12008.html) uploaded

Here's a concrete example: 

- I decide as an information architect that 
my deliverables need to have short descriptions, because otherwise my hub 
linking pages that draw from them look bad. 
- so I ask my specializer to implement a constraint in my schemas to make 
shortdesc required 
- I begin reusing 
content from other groups, some of whom have implemented the constraint, some of 
whom haven't 
- when I conref in a topic 
from a group that hasn't implemented the constraint, I expect a warning to the 
effect that my constraint hasn't been applied to the stuff I'm pulling in - 
similar to the warning I would expect when pulling in content that includes 
domains that might need to be generalized. 

If I don't have a way to signal the usage of constraints to processors, I 
have no easy way to get warnings or errors from my processors. 

Same thing as domains, same reasons, domain 
checking already done in conref, so not an academic thought. 

Michael Priestley
Lead IBM DITA 
Architect 
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25

"Eliot Kimber" <ekimber@reallysi.com>

08/22/2007 06:19 AM

To	dita@lists.oasis-open.org
cc
Subject	RE: [dita] Groups - Proposal 12008 - vocabulary and integration constraints (HTML) (IssueConstraints12008.html) uploaded

From: Deborah_Pickett@moldflow.com 
[mailto:Deborah_Pickett@moldflow.com] 
Sent: Tuesday, August 21, 2007 
7:00 PM
To: Erik Hennum
Cc: dita@lists.oasis-open.org; 
Grosso, Paul
Subject: RE: [dita] Groups - Proposal 12008 - vocabulary 
and integration constraints (HTML) (IssueConstraints12008.html) uploaded 
  

Hi TC, 

I should be upfront and say that I've already had a couple 
of rounds of feedback with Erik over this proposal, so I have had longer to 
digest it than many. 

There are (at least) two aspects to #12008, and though I 
don't think that they can be entirely separated, it's worth taking note of them 
as independently as you can. 

1. The example XSDs and DTDs demonstrate 
an increased level of parameterization in the infotype modules (topic.mod, 
task.mod, hi-d.mod).  Attribute lists are defined as entities; each element 
has its own entity for the content model.  Fine control over content models 
with the DITA 1.0 and 1.1 DTDs is quite difficult because of this lack of 
paramaterization.  I would hope that this aspect isn't controversial, but I 
could be wrong. 
[WEK] I 
think this increased parameterization is absolutely essential—I guess I didn’t 
realize it was part of the proposal. I definitely support this aspect.  But 
this can and should be done whether or not the constraint specification 
attributes are part of the architecture.
2. 
The @constraints attribute, and what information it contains (and I suppose how 
its content is spelled).  This, apparently, *is* controversial.  I'd 
be curious to know exactly why, given that the existing @domains attribute 
doesn't cause consternation (that I know about). 
The domains= attribute preexisted DITA 1.0 and was therefore just a rule. 
Plus it’s simple enough and the utility of it as at least documentation is clear 
enough: you’d like to be able to quickly tell what domains an instance uses in 
case you need to configure a processor or something. Fair enough. 
But constraints are another 
kettle of fish: the specification of constraints implies a requirement to check 
or enforce those constraints in some processing contexts. Constraint languages 
are complex (I’ve been involved with a number of them over my career) and 
implementing constraint checking is complex. The specification development cost 
alone of any sort of useful constraint language will be high. For an editor 
vendor like PTC or Just Systems, the potential implementation cost will be high. 
From a DITA user standpoint, the cost of having to learn, understand, and apply 
constraints will be high. Since the practical benefit as far as I can tell 
accrues from the work done at the DTD or schema level, it calls into question 
the value of also specifying the constraints as attributes. 
Michael says that there is high value in 
being able to specify these constraints. If they are expressed at the DTD or 
schema level then I agree 100% because obviously they will enable much greater 
control that authors need and want. 
But as expressed through attributes their value is much 
more limited unless editors and validators implement some processing based on 
those attributes. If they aren’t processed then they’re just documentation and I 
think it would be hard to argue that enabling instance-bound documentation is 
really that compelling. The only case where having that documentation extant in 
the instance would be useful would be when you’re presented with documents with 
no associated DTD or schema but it seems highly unlikely that such documents 
would be involved in an authoring process since few people would develop a 
system that supported authoring but didn’t involve DTDs or schemas. Rather, such 
documents are only likely to be consumed by processors that don’t need to care 
about validation at that level—they need only check the DITA-level or 
specialization-specific constraints that are important to the processing at 
hand, that is, validation by failure. 
I’m also sensitive to putting into standards things that 
will make the standard harder to understand and teach—a hard lesson learned from 
HyTime and SGML. I put every feature through the “how would I address this 
feature in my DITA class?” test.  DITA is already hard enough for people to 
learn, understand, and apply. 
Cheers, 
E.