Re: [dita] Groups - DITA 1.3 Proposal 13107 - Default Scope, Format, and Type Values (HTML) uploaded

[Chris Nitchie <chris.nitchie@oberontech.com>]

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.

- http://docserver.foo.com/project1/folder1/myTopic.dita

- ../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
HTML Version 
Download Latest Revision
Public Download Link

---

Submitter: Mr. Christopher Nitchie
Group: OASIS Darwin Information Typing Architecture (DITA) TC
Folder: Drafts
Date submitted: 2013-03-05 10:07:34
Revision: 3

Chris Nitchie

Oberon Technologies, Inc.

2640 Wildwood Trail

Saline, MI 48176

Main: 734.666.0400

Direct: 734.330.2978

Email: chris.nitchie@oberontech.com

www.oberontech.com