Michael wrote:
> What if we preserve semantics, but in a way that
processors can distinguish
> between ones that are guaranteed valid (ie
schema-supplied) versus ones that
> aren't (ie derived from other schemas). Then a
processor that is simply doing
> class-based matching can't be fooled into accepting
invalid content, but a
> processor that wants to do more isn't prevented.
This would work fine.
It could apply to both the generic to
specialized case and to the specialized to the generic case.
At PTC we currently do pretty much this
using a combination of @class and a new attribute we add (@atirds:mapelement),
but we’d benefit from formalizing what we do since what we do now was
developed in a pretty ad hoc fashion.
I don’t think we want to say what
attribute to use, just that the appropriate properties should be available for
use during processing in a fashion that makes sense for the given
implementation. I suspect that we might want to provide a list to provide
more information, so to extend your example
mapcontext=”topicref
chapter” or mapcontext=”chapter topicref”
Are the properties element based or should
we be thinking of something that is more like the class attribute tokens?
mapcontext=”
map/topicref bookmap/chapter “ or mapcontext=” bookmap/chapter
map/topicref “
Or is this just an implementation detail
that the specification doesn’t need to worry about?
-Jeff
From: Michael
Priestley [mailto:mpriestl@ca.ibm.com]
Sent: Tuesday, June 16, 2009 1:40
PM
To: Ogden, Jeff
Cc: dita
Subject: RE: [dita] referencing a
bookmap from a map
Hi Jeff,
>We’ve got two choices (wants vs. doesn’t want
or overrides vs. doesn’t override) and we seem to need
>to pick one or the other. Either way we are left
with the same question, how does an author pick
>the other choice. One solution is to provide an explicit
way for the user to make the choice.
>The other way is to define a set of rules that
effectively says that it isn’t reasonable to make the
>other choice and so we won’t allow it or more
likely that we won’t make it easy.
Good
summary. I think there's a potential third solution - it may be stupid, I'm
just thinking this through.
What
if we preserve semantics, but in a way that processors can distinguish between
ones that are guaranteed valid (ie schema-supplied) versus ones that aren't (ie
derived from other schemas). Then a processor that is simply doing class-based
matching can't be fooled into accepting invalid content, but a processor that
wants to do more isn't prevented.
For
example: topicref to chapter gets resolved to topicref with
outputclass="chapter" . Then a bookmap processor that knows what's
coming can handle it, and one that doesn't, isn't hit.
Not
suggesting that's how to write it up in the spec - just trying to figure out a
way to meet both reqs.
Michael
Priestley, Senior Technical Staff Member (STSM)
Lead IBM DITA Architect
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25
|
"Ogden, Jeff"
<jogden@ptc.com>
06/16/2009 12:47 PM
|
|
To
|
Michael Priestley/Toronto/IBM@IBMCA
|
|
cc
|
"dita"
<dita@lists.oasis-open.org>
|
|
Subject
|
RE: [dita] referencing a bookmap from a map
|
|
Comments below.
-Jeff
From: Michael
Priestley [mailto:mpriestl@ca.ibm.com]
Sent: Tuesday, June 16, 2009 12:12 PM
To: Ogden, Jeff
Cc: dita
Subject: RE: [dita] referencing a bookmap from a map
>What happens by default shouldn’t matter to the DITA specification.
The 1.1 specification is
>entirely silent about these sorts of details. You can sort of guess from
the names and some
>of the element descriptions, but that is all you are doing. I think the 1.2
specification
>should remain silent on these sorts of details.
So what is 12055 doing? Are those required behaviors, or just suggested, or
something else?
I’m not sure. I think of it as a requirement,
that if you use a chapter to reference a topicref that the topicref MUST be
treated as a chapter.
But 12055 allows for exceptions, but doesn’t say how
exceptions are defined or recognized or even who makes the exceptions (the
specification author, the DTD author, the processing implementer, the map
author, …). So what is a requirement that allows exceptions? Is that
still a requirement or a suggestion or something else? I have no idea.
To clarify:
- I'm suggesting behavior only for aggregating processes - not every possible
map process
I understand and agree.
- I'm suggesting behavior that would be a default, not a requirement.
I don’t know what this means. Can a vendor
deliver non-default behavior out of the box? Is it just that the default
behavior has to be available somehow upon request?
Or to move this into standards language is this something
that is required (MUST), strongly recommended (SHOULD), or allowed (MAY)?
I'd
actually be happy with being parallel to whatever strength we put behind 12055.
Just as long as we're consistent.
- as Robert Anderson noted, if we're going to specify that a <chapter>
reference to a bookmap should resolve into a set of <chapter> references
to the bookmap's parts, then we should have the same level of specification for
what a <topicref> does (and I think it should do something
parallel)
I usually push for consistency. 12055 doesn’t directly
address this case and so we would be consistent if we said that specialized
topic references override generic topic references. And I think that that gives
a better result than saying that the referencing topic reference override the
referenced topic reference.
- otherwise, how does a user get rid of semantics that don't make sense for the
reusing context? for example, a writer reusing a bookmap into an Eclipse TOC
who doesn't want "chapter xxx" generated.
Going with the referencing overrides referenced approach
doesn’t answer the question. You still need to ask “how does a user
get rid of semantics that don’t make sense for the reusing context? For
example, a writer reusing a bookmap into an Eclipse TOC that does want “chapter xxx”
generated.”
We’ve got two choices (wants vs. doesn’t want or
overrides vs. doesn’t override) and we seem to need to pick one or the
other. Either way we are left with the same question, how does an author
pick the other choice. One solution is to provide an explicit way for the user
to make the choice. The other way is to define a set of rules that
effectively says that it isn’t reasonable to make the other choice and so
we won’t allow it or more likely that we won’t make it easy.
Michael Priestley, Senior Technical Staff Member (STSM)
Lead IBM DITA Architect
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25