[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] definition of resource
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 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]