TIPP: meaning of Name vs Location of ObjectFile is not clear from docs

[GoogleCodeExporter]

From Alan & Jason at Linport:
> We think that the two elements of the ObjectFile element:
>   - Name
>   - Location
> are the full name as received from outside the TIPP and the possibly 
shortened name (for the zip), respectively.
> Is that correct?
> If so, it is not clear from the TIPP definition.

Their reading is correct; clarify the relevant language to make sure it is 
apparent from the documentation.

Original issue reported on code.google.com by tingley on 9 May 2012 at 5:42

[GoogleCodeExporter]

Original comment by tingley on 23 Jul 2012 at 3:46

• Added labels: Milestone-TIPP1.5

[GoogleCodeExporter]

Issue 21 has been merged into this issue.

Original comment by tingley on 23 Jul 2012 at 3:49

[GoogleCodeExporter]

Additional language from the July 20 TIPP 1.5 draft:
Object Name vs Object Path

Package Objects are described in the manifest with both a path and a path.  
While in some cases these two values may be identical, it is important that 
they be treated separately.
The name represents an abstract identifier for the resource.  The name may be 
arbitrarily long and contain any Unicode character.  The name may have meaning 
outside the TIPP; for example, it may be a user-readable file name, or a 
location within a resource hierarchy in a TMS.  TIPP implementations must not 
modify Object names during processing.
In contrast, the path is an implementation detail internal to TIPP. Paths 
identify specific locations within the TIPP itself.  In the current 
implementation, the path represents a location within the payload ZIP archive.  
Paths are subject to restrictions defined both by the ZIP format and by the 
file systems on which it is expected a TIPP may be manipulated.  The format of 
paths is described in Format of Package Object Paths.
Paths are created when a given TIPP is assembled and have no meaning beyond the 
scope of that TIPP.  A single Object that is included as part of a request TIPP 
and a subsequent response TIPP is expected to have a constant name, but may be 
assigned a different path for each TIPP that carries it.  An implementation 
must not assume that a particular path will be assigned to a certain Object, 
even if it has been assigned to that object in a previous TIPP.

Original comment by tingley on 23 Jul 2012 at 3:53

[GoogleCodeExporter]

Original comment by tingley on 2 Mar 2013 at 3:54

• Changed state: Fixed