[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] Why There are Constraints on Conref
Michael's proposal makes a lot of sense, as there are definitely many
cases in which you would not want to have an element type be presented
to authors, but you would not actually mind if that element got into the
document. XMetaL does conref validation and I'm told that Michael's
proposal would not be a big deal for the XMetaL development team to
support, however we'd like to hear from more CMS vendors in terms of
whether their tools will be able to skip validation for weak
constraints. It will be a problem if the authoring tool thinks a conref
is valid but the CMS thinks it's invalid.
Don, I agree that due diligence is warranted. To partly answer your
question, I personally have very little bandwidth for the next couple of
months to work on it. I'd like to add another concern about validation
of strong constraints though:
The purpose of defining what makes an conref invalid is to ensure that
what gets put into a document via conref can be processed in a
predictable way. The problem we have is that our DITA 1.2 definition of
"what makes a conref invalid" is too broad, so it will produce a lot of
false positives. So far I've found that DITA 1.0 and 1.1 implementers
can get their head around the concept that you can't make a conref
between different element types unless their specialization properties
are such-and-such.
However, implementers have a very difficult time getting their head
around the idea that you can't conref between a map and a topic even if
the source and target element names *and content models* are exactly the
same. When source and target element types have identical content
models, people expect to be able to conref between them, and if this
fails they consider the case to be a false positive. Educating people
helps them understand that they can't get what they expect, but it
doesn't stop them from expecting it.
I don't have a concrete suggestion for redefining "what makes an invalid
conref" to allow conrefs between any two elements that have compatible
content models. But if we can do it, and can do it in a way that tools
can support, it would be a great improvement to the DITA standard.
Regards,
Su-Laine
Su-Laine Yeo
Interaction Design Specialist
JustSystems Canada, Inc.
Office: 778-327-6356
syeo@justsystems.com
www.justsystems.com
-----Original Message-----
From: Don Day [mailto:dond@us.ibm.com]
Sent: Monday, September 28, 2009 12:42 PM
To: dita
Subject: Re: [dita] Why There are Constraints on Conref
Tomorrow I plan to have the DITA TC discuss the due process for
qualifying
this late proposal. Considering the importance of the discussion and the
general agreement with Michael's suggestion, the due diligence seems
warranted. I think everyone (including end users of the 1.2
specification)
will appreciate our being convinced, one way or the other, of the value
of
this suggestion for the issues that have been raised.
We seem to be assuming that Michael will do the deep thought, but if we
approve the investigation, I want to be sure that he and others do have
the
bandwidth to work the examples and be assured that we have a solid
proposal.
Regards,
--
Don Day
Chair, OASIS DITA Technical Committee
Architect, Lightweight DITA Publishing Solutions
Email: dond@us.ibm.com
11501 Burnet Rd. MS9033E015, Austin TX 78758
Phone: +1 512-244-2868 (home office)
"Where is the wisdom we have lost in knowledge?
Where is the knowledge we have lost in information?"
--T.S. Eliot
From: ekimber <ekimber@reallysi.com>
To: "Ogden, Jeff" <jogden@ptc.com>, Michael Priestley
<mpriestl@ca.ibm.com>
Cc: dita <dita@lists.oasis-open.org>, <rob@ascan.ca>, Su-Laine
Yeo
<su-laine.yeo@justsystems.com>
Date: 09/28/2009 01:55 PM
Subject: Re: [dita] Why There are Constraints on Conref
I agree that we should have a formal proposal and some time to think it
through. I'm sure that simply having MP take the time think through the
language of a formal proposal would do a long way toward either making
it
reliably solid or determining that it's ill advised upon deeper
consideration.
Cheers,
E.
On 9/28/09 1:51 PM, "Ogden, Jeff" <jogden@ptc.com> wrote:
> If we do implement weak constraints for DITA 1.2 or 1.3, what sort of
> constraint would we include for task in ditabase (strict or
weak-strict,
> I assume that general is not an option) and what sort of constraint
> would we include in task.dtd (strict or weak-strict)?
>
>
>
> Is a weak constraint something that is decided by the constraint
author
> or is it something that can be overridden in a customized doctype
shell?
>
>
>
> Just writing the name weak-strict gave me the creeps, but I guess we
> could pick a better name or perhaps task.dtd is always strict and
strict
> always implies weak, so the name remains task which is strict task or
> weak-strict task.
>
>
>
> My main concern here is that adding weak constraints is going to make
> something that is pretty complicated already even more complicated. It
> seems that few people understand it now and so making things more
> complicated isn't likely to help. But I guess if people are willing
to
> use the doctype shells on "faith" without really understanding and if
> the information designers do a good job or are lucky, then people
won't
> run into problems and life will be good (as good as it was in DITA 1.0
> and 1.1 anyway).
>
>
>
> I also worry that making changes like this in a rush at the last
minute
> without a real proposal may cause us to doing something without really
> thinking it through and we may come to regret it later.
>
>
>
> -Jeff
>
>
>
>
>
> From: Michael Priestley [mailto:mpriestl@ca.ibm.com]
> Sent: Friday, September 25, 2009 2:05 PM
> To: ekimber
> Cc: dita; Ogden, Jeff; rob@ascan.ca; Su-Laine Yeo
> Subject: Re: [dita] Why There are Constraints on Conref
>
>
>
>
> Eliot, I think that's an eloquent description of the rationale for the
> current situation, and it's certainly where my thinking is coming from
> as well.
>
> I did have a thought on how we might be able to achieve a compromise
of
> sorts, preserving the strict validation that we both consider
necessary
> for robust processes, while allowing for broader reuse scope in some
of
> the cases Rob and others have been asking for (including task->general
> task).
>
> Here's my thought:
>
> - if the doctype developer knows upfront whether a constraint is just
an
> authoring guideline or whether it's a strict business requirement,
they
> could annotate the constraint on inclusion
> - constraints noted as "weak" would be ignored by conref validation,
and
> would be considered unreliable by processors, which would need to
assume
> the constraint wasn't there as well
>
> Example:
> - group A introduces a constraint that makes title in fig required -
> they have a figlist generator that depends on this, so they make the
> constraint required - if someone tries to conref from a place that
> allows title-less figs, they'll get an error, and will have to
negotiate
> with the other team to introduce the constraint in their shared
content
> - group B introduces a constraint that makes <ul> unavailable in <p>,
> because they think it's simpler for their authors. But they don't
depend
> on it, the output looks the same whether they allow <ul> inside <p> or
> not, and they may need to conref content from another team that
doesn't
> use the constraint. So they make the constraint "weak" instead of
> required.
>
> Technical complexity:
> - add a flag to constraints to indicate when they are included as
"weak"
> - eg - domains=" w(myconstraint) "
> - add a check to conref validation that ignores weak constraints when
> determining validity
>
> If we wanted to, we could then implement our strict task as a weak
> constraint, so it would be able to conref from loose task.
>
> I think this might address the concerns of both sides - it gives us
> strong constraints when there are business or processing requirements
on
> the constrained structure, but allows reuse in other cases.
>
> All that said, I'm very aware of how late in the cycle we are, and I
> don't think the cross-constraint use case is actually going to come up
> that often. So there's probably a few questions to ask:
>
> - is this a useful idea?
> - does it address the use cases of both sides?
> - if it is, is it useful enough to change in 1.2, or should it wait
till
> 1.3?
>
> Michael Priestley, Senior Technical Staff Member (STSM)
> Lead IBM DITA Architect
> mpriestl@ca.ibm.com
> http://dita.xml.org/blog/25 <http://dita.xml.org/blog/25>
>
>
>
> From:
>
> ekimber <ekimber@reallysi.com>
>
> To:
>
> <rob@ascan.ca>, Su-Laine Yeo <su-laine.yeo@justsystems.com>, Michael
> Priestley/Toronto/IBM@IBMCA
>
> Cc:
>
> dita <dita@lists.oasis-open.org>, Jeff Ogden <jogden@ptc.com>
>
> Date:
>
> 09/24/2009 11:52 PM
>
> Subject:
>
> Re: [dita] Why There are Constraints on Conref
>
>
>
> ________________________________
>
>
>
>
> On 9/24/09 10:23 PM, "Rob Hanna" <rob@ascan.ca> wrote:
>
>>> They might be making content outside
>>> their environment unusable *by them*
>>> but they would not be making their
>>> content unusable to others who use fewer
>>> constraints.
>>
>> What if instead of having fewer constraints, they have different
> constraints?
>> This is not simply a matter of just two task variations. Over time
the
>> variations of standard topic types introduced through constraints
will
> grow.
>
> This is why you have the domains attribute at all: so you can analyze
> the
> constraints at use in two DITA documents to determine if they are
> compatible. This at least lets you detect this situation early, rather
> than
> late (such as after a publication has been published).
>
>> For example, consider one possible scenario I see where this might
> present a
>> problem:
>>
>> "Over the course of several years a department's style guide changes
> several
>> times through reorgs and acquisitions - each time enforced with a
> different
>> set of constraints introduced. There is no budget to convert the
older
>> content. Over time reuse opportunities are lost and content must be
> duplicated
>> to suit different doc sets written to adhere to separate
constraints."
>>
>> As it stands now, constraints do not deprecate gracefully as would
> domain
>> specializations. Even substructures within structurally specialized
> content
>> can generally be reused safely.
>
> Note that it is *easy* to remove constraints: you simply update your
> shells
> to stop including the constraint modules. No need to modify the
> documents
> involved.
>
> That means that given two sets of content that have incompatible
> constraints
> you can make them compatible by changing their governing shells to be
> less
> constrained.
>
> But in fact I think what you are expressing is a problem inherent in
any
> interoperation situation. DITA isn't changing the fact that two
> interchanging communities might have divergent rules over time such
that
> there may be data and processing interoperation problems: that's an
> unavoidable fact of life.
>
> What DITA is saying is "we're giving you a way to detect that case
> early,
> rather than late" and make an informed decision about how to react.
>
> In practice I think most DITA users will tend to avoid constraints
> simply
> because any constraint, by its nature, tends to impede bidirectional
> interchange.
>
> The only reason we're having this discussion at all is because DITA
1.0
> inherited an over-constrained task model from IBM, something we should
> have
> fixed in 1.1 but didn't. It's only now that we have the constraint
> mechanism
> that we can fix the problem (overconstrained tasks) in a way that
allows
> backward compatibility without having to define a completely different
> task
> base type and specialization.
>
>> This is an issue that can only get more complex over time. In my
> opinion,
>> processors must be designed to handle the base (or call it general or
> loose)
>> structures with warnings to ensure seamless exchange of content.
>
> But it's not that easy: there may be processing cases where it would
be
> at
> best wrong, at worst impossible, to properly process and render
> unconstrained content in a constrained context, because the
constraints
> are
> there, in that case, to enable or ensure a particular presentation. So
> you
> can't simply say "processors have to be able to process any
combination
> of
> stuff".
>
> Cheers,
>
> E.
>
> ----
> Eliot Kimber | Senior Solutions Architect | Really Strategies, Inc.
> email: ekimber@reallysi.com <mailto:ekimber@reallysi.com
> <mailto:ekimber@reallysi.com> >
> office: 610.631.6770 | cell: 512.554.9368
> 2570 Boulevard of the Generals | Suite 213 | Audubon, PA 19403
> www.reallysi.com <http://www.reallysi.com <http://www.reallysi.com/> >
> | http://blog.reallysi.com <http://blog.reallysi.com/>
> <http://blog.reallysi.com <http://blog.reallysi.com/> > |
> www.rsuitecms.com <http://www.rsuitecms.com
<http://www.rsuitecms.com/>
>>
>
>
> ---------------------------------------------------------------------
> 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://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php>
>
>
>
>
>
----
Eliot Kimber | Senior Solutions Architect | Really Strategies, Inc.
email: ekimber@reallysi.com <mailto:ekimber@reallysi.com>
office: 610.631.6770 | cell: 512.554.9368
2570 Boulevard of the Generals | Suite 213 | Audubon, PA 19403
www.reallysi.com <http://www.reallysi.com> | http://blog.reallysi.com
<http://blog.reallysi.com> | www.rsuitecms.com
<http://www.rsuitecms.com>
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]