Chris
Thanks for explaining further. One small note. Not sure I said scope describes the linkee – rather my focus was that link scope may affect the behavior of the link within the linkor – for example an editor may give you the ability to open a scope=”local” file for editing but not allow this for a scope=”external” file.
Agreed, for instance, absolute URL forms in our product do not use http: - we use xdocs: in one of our editor connectors and the editor calls back to us. However http is a very well supported standard for getting bytes so not sure why nobody would ever use absolute http links, or switch to them in certain contexts.
This proposal is survivable and there can be numerous strategies to flip content into an explicit form – we should note that the explicit form is considered identical so users don’t complain that we decorated their content. Also CMS vendors will likely have to upgrade their link checking code so they can properly derive this implicit scope as scope is important for link checking, especially on import.
Anyhow, enough said for now.
cheers
Jim
From: Chris Nitchie [mailto:chris.nitchie@oberontech.com]
Sent: March-06-13 5:52 AM
To: Jim Tivy
Cc: dita@lists.oasis-open.org
Subject: Re: [dita] Groups - DITA 1.3 Proposal 13107 - Default Scope, Format, and Type Values (HTML) uploaded
Jim,
Thanks, that's clarifying. And I agree, from a formal perspective, these changes are a tad… I'll say "unsavory." But real-world experience has shown that the current defaults, especially for @scope, lead to common errors for even expert authors. There are even xrefs to external websites in the DITA spec itself that don't specify a @scope!
To specifically address your point, @scope doesn't describe the target resource itself. Rather, it describes a relationship between the target resource and the current document. When the URI is absolute, particularly to an http or https resource, I'd argue that assuming that the target is external is reasonable. Whereas when the target resource is addressed via relative URI, whatever the scheme of the resolved absolute URI, it's reasonable to assume that the target resource is local.
And yes, temporary ephemeral views of files may convert the href to an absolute form for convenience; I've implemented DITA processors myself that do exactly this. But (1) that would only cause problems when the resolved absolute href has a scheme of http: or https:, which I think is an exceptional case; and (2) any process that does such expansion of relative hrefs should also make @scope, @format, and @type explicit in the generated ephemeral view, eliminating any confusion for downstream processes.
Chris
On Mar 5, 2013, at 8:46 PM, Jim Tivy <jimt@bluestream.com> wrote:
Hi Chris N and All
I read through the proposal – nicely written.
I am not sure I articulated the counter argument, but in short: Addressing should be independent of behavior of the resource.
This restriction on addressing form did not exist before.
Addressing something by an absolute address and a relative address – in a certain host context – should have identical results. Requiring addressing form consistency across all tools seems restrictive. Consider the following three addressing forms with a server of http://docserver.foo.com and two folders project1/folder1 and project1/folder2. To a web savy person all three of these addresses refer to the same file and they would expect the same behavior.
- ../folder1/MyTopic.dita as referenced from ../folder2/MyTopic2.dita resolved to #1.
- /project1/folder1/MyTopic.dita resolved to #1
Under the current spec you get the same behavior regardless of how the resource is addressed. The setting of the scope attribute would be consistent across all addressing forms.
In this proposal the first form would default to scope=”external”, and the other two scope=”local” even tho according to URL theory they address the same resource within the same server context. The job of an address is to deliver the bytes, not dictate behavior.
Implicit in the proposal is that no tool can ever use the first form on local dita content because dita scope would become dependent on the addressing form used.
Although I think we can agree that persisting absolute links is bad practice, there is nothing that says temporary ephemeral views of files, such as those found in an editor, have to use relative links to work. But with this proposal, we are saying that in order to get the right scope behavior carefully ensure your link forms every step of the way.
Some of the other changes in the proposal make sense, but switching behavior on addressing form is a bit unsettling – or rather I do not have the strength of conviction to say – “never ever flip your links to an absolute form in any temporary view for any reason”.
cheers
Jim
From: dita@lists.oasis-open.org [mailto:dita@lists.oasis-open.org] On Behalf Of Christopher Nitchie
Sent: March-05-13 10:08 AM
To: dita@lists.oasis-open.org
Subject: [dita] Groups - DITA 1.3 Proposal 13107 - Default Scope, Format, and Type Values (HTML) uploaded
Submitter's message
Adding mailto: to the list of schemes treated as 'external' by default.
-- Mr. Christopher Nitchie
Document Name: DITA 1.3 Proposal 13107 - Default Scope, Format, and Type Values (HTML) Description Submitter: Mr. Christopher Nitchie |
Chris Nitchie
Oberon Technologies, Inc.
2640 Wildwood Trail
Saline, MI 48176
Main: 734.666.0400
Direct: 734.330.2978
Email: chris.nitchie@oberontech.com
