Re: [dita] definition of resource

[Eliot Kimber <ekimber@contrext.com>]

I think we're agreement then--the current language in the DITA spec is
consistent with the RFC's definition of resource. The language quoted is
simply trying to make a distinction between "DITA resources" and "non-DITA
resources" in order to then explain the DITA-specific fragment identifiers
used to address DITA resources. But that is all consistent with the URI
meaning of resource.

Cheers,

E.
—————
Eliot Kimber, Owner
Contrext, LLC
http://contrext.com




On 3/31/15, 12:30 AM, "Jim Tivy" <jimt@bluestream.com> wrote:

>Agreed
>
>I think this text below from the DITA Spec really defines what is meant
>by a resource within the context of DITA which I think is within the
>spirit of the URI definition.
>There is no problem with us limiting the scope of what a resource may be
>in our context and thus defining what a resource may be.
>
>Here is the embedded definition of "resource" from the current 1.3 DITA
>Spec that you eluded to in your comment.
>
>3.3.4.2 URI-based (direct) addressing
>
>URI references address "resources" and, optionally, subcomponents of
>those resources. In the context of DITA,
>a resource is a DITA document (map, topic, or DITA base document) or a
>non-DITA resource (e.g., a Web page,
>a PDF document, etc.). For DITA resources, fragment identifiers can be
>used with the URI to address individual
>elements. The fragment identifier is the part of the URI that starts with
>a number sign ("#"), e.g., "#topicid/
>elementid". URI references may also include a query component, introduced
>with "?". DITA processors MAY
>ignore queries on URI references to DITA resources.
>
>I think this kind of definition is within the spirit of the URI spec but
>it should be moved to a more central place.
>
>The URI RFC says:
>"This specification does not limit the scope of what might be a
>resource; rather, the term "resource" is used in a general sense
>for whatever might be identified by a URI."
>
>I think "resource" defined within the context of DITA is a fundamental
>concept - ideally in a glossary.
>Saying that in local scope most processors will use an http or file
>scheme to make the URI references into full URIs (URIs must have schemes
>to be URIs).
>For interoperability we should suggest DITA source should assume implied
>http" or file based: schemes.
>
>Jim
>
>> -----Original Message-----
>> From: Eliot Kimber [mailto:ekimber@contrext.com]
>> Sent: March-30-15 6:52 PM
>> To: Jim Tivy; dita@lists.oasis-open.org
>> Subject: Re: [dita] definition of resource
>> 
>> The term is defined: in the referenced RFC.
>> 
>> The DITA spec can refer to that definition or it can repeat it (with
>>attribution).
>> But we cannot change the meaning of the term "resource" as it applies
>>to the
>> processing of URIs. We do make the distinction between
>> *DITA* resources (elements within DITA documents) and non-DITA
>> resources.
>> 
>> Cheers,
>> 
>> E.
>> 
>> 
>> —————
>> Eliot Kimber, Owner
>> Contrext, LLC
>> http://contrext.com
>> 
>> 
>> 
>> 
>> On 3/30/15, 8:39 PM, "Jim Tivy" <jimt@bluestream.com> wrote:
>> 
>> >I think the term should be defined - it is too core to our discussion.
>> >And the definition should be as restrictive as.  If we use the term
>> >"identity" as referenced below we have to determine what does it mean
>> >to have identity in DITA.  It would seem a key, a subject and even in
>> >the absurd case any element could have identity.
>> >We need to be restrictive where we can.  Or perhaps we could have
>> >hyphenated definitions like addressable-resource where we define what
>> >an address is (map,topic, binary or fragment) and what an
>> >addressable-resource is.
>> >
>> >I think being vague or abstract is not good unless we can see that
>> >being concrete hampers valid interpretations or uses of DITA.
>> >
>> >> -----Original Message-----
>> >> From: Eliot Kimber [mailto:ekimber@contrext.com]
>> >> Sent: March-30-15 5:33 PM
>> >> To: Jim Tivy; dita@lists.oasis-open.org
>> >> Subject: Re: [dita] definition of resource
>> >>
>> >> By "resource" we mean what the URI specification means by "resource":
>> >>
>> >> Resource
>> >>
>> >>          A resource can be anything that has identity.  Familiar
>> >>          examples include an electronic document, an image, a service
>> >>          (e.g., "today's weather report for Los Angeles"), and a
>> >>          collection of other resources.  Not all resources are
>>network
>> >>          "retrievable"; e.g., human beings, corporations, and bound
>> >>          books in a library can also be considered resources.
>> >>
>> >>
>> >> http://www.ietf.org/rfc/rfc2396.txt
>> >>
>> >> DITA is a Web application (as is XML), so for the purposes of
>> >>addressing, all  addresses that are not keys are URIs and therefore we
>> >>use the IETF and W3C  terminology that applies in those cases.
>> >>
>> >> Cheers,
>> >>
>> >> E.
>> >> —————
>> >> Eliot Kimber, Owner
>> >> Contrext, LLC
>> >> http://contrext.com
>> >>
>> >>
>> >>
>> >>
>> >> On 3/30/15, 7:18 PM, "Jim Tivy" <jimt@bluestream.com> wrote:
>> >>
>> >> >Wiki has a review of the history of resource
>> >> >http://en.wikipedia.org/wiki/Web_resource
>> >> >
>> >> >Along the lines of some fundamental definitions - I think we need a
>> >> >DITA definition of what we mean by resource.
>> >> >
>> >> >Something like, a resource in DITA is anything that has identity.
>> >> >This includes topics, maps and XML fragments within maps.
>> >> >This does not include subjects defined in a subject def (or does
>> >> >it?)
>> >>
>> >
>> >
>> >
>> >---------------------------------------------------------------------
>> >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
>
>