Thanks
Michael. I see the value in the proposal and I don’t have a specific
objection to it, however to start the discussion I’ll recap a couple of things
I’ve mentioned in off-list discussions and in a previous TC meeting:
1)
Constraining
a document will affect copy/paste as well as conref. If you constrain out
<lq> elements, for example, you won’t be able to paste anything
that contains a <lq> element and have it be valid. Depending on your
authoring tool, it could mean not being able to paste that content at all unless
you remove the <lq> element first.
If
an organization’s goal is to simplify the user experience for authors (by
presenting a smaller element list), but they don’t want to strictly
disallow any structures, using constraints will be a problematic way to achieve
their goal regardless of whether we adopt this proposal.
2)
There are features on the DITA 1.3 list that I think are higher-priority than
this proposal.
I’m
open to being persuaded otherwise, but for now I think that we should focus on what
is already in 1.2.
Happy
Thanksgiving to the Canadians, by the way! I’ll be out of the office on
Monday Oct 12.
Best
regards,
Su-Laine
Su-Laine Yeo
Interaction Design Specialist
JustSystems Canada, Inc.
Office: 778-327-6356
www.justsystems.com
From: Michael Priestley
[mailto:]
Sent: Friday, October 09, 2009 2:07 PM
To:
Subject: [dita] weak/strong constraint proposal
The following
proposal is relative to the existing constraint design documented here:
http://www.oasis-open.org/committees/download.php/25090/IssueConstraints12008.html
I'm starting
with the assumption that we would want the default or normal behavior to be
weak constraints - so I'm proposing a notation to declare when a constraint
should be respected/required for interoperability, and letting the default be
to assume that the constraint is not required.
------------------
Proposed
notation: optionally precede the normal constraint declaration with an
"s" for strong.
Example:
s(topic hi-d
basicHighlight-c)
This notation
is parallel to the notation for attribute domains, where a leading
"a" is used to identify the value as having special meaning.
Normally-declared
constraints are to be ignored by conref processing, in order to ease sharing
between groups that have implemented constraints primarily to enforce authoring
guidelines, rather than for strict processing requirements.
If there is a
processor or other strong dependency on a constraint being present, then the
constraint can be declared in the document type with the prefix "s".
The constraint should then be handled in exactly the way currently described in
the existing design.
--------------------
Let me know if
this is enough - it's a fairly simple proposal, relative to the existing one
:-) But if it would be useful for me to go in and edit the original, I can.
Michael
Priestley, Senior Technical Staff Member (STSM)
Lead IBM DITA Architect
http://dita.xml.org/blog/25
