OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Discussion of conref href= value syntax


In the section "Using conref to refer to an element within a topic" is 
this text:

"The conref value follows the same conventions as HTML for what HTML 
calls a ″fragment identifier″—a required ″#″ separator separates an 
optional filename from the fully qualified id (in the form 
topicid/elementid). Note that the ID of the topic must be included in 
the reference before the ID of the element. To refer to target content 
in a different file, put the full URL of that topic before the # character."

This is not technically correct in that the syntax of URLs is defined by 
the HTTP specification and not the HTML specification. That is, what 
HTML does is not a "convention" but what the URL specification *requires*.

Using the terminology from RFC3986, I think this paragraph should say 
something like:

The value of conref is a URI that includes (or consists entirely of) a 
fragment identifier consisting of the ID of the topic that contains the 
element that is the target of the content reference, a slash ("/"), and 
the ID of the target element. If the URI consists of only a fragement 
identifier, the target element must be in the same XML document as the 
reference.

Likewise, the following section on conref within maps should read 
something like:

Within a map, the conref attribute references an equivalent element in 
the same map or another map. [NOTE: I purposefully omitted the "will be 
copied" text.] The value of conref is a URI that includes (or consists 
entirely of) a fragment identifier consisting of the ID of the target 
element. If the URI consists of only a fragement identifier, the target 
element must be in the same XML document as the reference. If the URI 
addresses a different resource that resource must be a DITA map document.

Note that as far as I can tell RFC3986 does not define a term that means 
"the part of the URI that is not the fragement identifier or query". If 
there is such a term the above might be clear by saying "a URI that 
consists of an (optional) thingy plus a fragment identifier...".

Also, I think that the following section "Using conref to refer to a 
map" could be combined with the preceding section to avoid having to 
repeat what was just said for conrefs within map.

I haven't taken the time to find all the places that specs talk about 
addressing syntax, but anywhere that the value is a URI the same sort of 
language should be used.

It would probably be useful to have a separate general statement about 
addressing and what forms of URI processors are expected to support. In 
particular, I would think that it's a requirement that all DITA 
processors support the HTTP schemes but are not required to support any 
other schemes for DITA-to-DITA references.

Cheers,

E.

-- 
W. Eliot Kimber
Professional Services
Innodata Isogen
8500 N. Mopac, Suite 402
Austin, TX 78759
(214) 954-5198

ekimber@innodata-isogen.com
www.innodata-isogen.com



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]