Re: [sdd] Issue 31

[Keisuke Fukui <kfukui@labs.fujitsu.com>]

Hi Christine,

 > Comments or suggestions? Has anyone in the ACS WG looked at package
 > aggregation scenarios?

The ACS doesn't include the scenario that aggregates another archive.

Having said that, your suggestion sounds fine to me.

 >     * How is the referenced package represented in the aggregating
 >       package descriptor? I'd suggest a file of type "package", which

I understood that your suggestion above as below:
the "File" element with the value "package" as its
"purpose" attribute contains the PackageDescriptor for
the aggregated package.

 >     * Are any files from within the referenced package included in the
 >       aggregating package descriptor? I'd suggest not - i.e. inclusion
 >       by reference.

I agree that a file should be listed only in the PackageDescriptor that
contains the actual file directly. The PackageDescriptor of the aggregating
package should not repeat the entry in its own PackageDescriptor.

P.S.
I used the UCC as indicated in the Writers Convention.

Regards,
Keisuke Fukui

Christine Draper wrote:
> I think that a "deploymentDescriptor" purpose would make sense. However, 
> it surfaces something else we need to work out - referenced packages. We 
> would need to be able to distinguish the deployment descriptor for a 
> package from those for referenced packages (content and requisites). 
> More generally, we need to work out how the contents of a referenced 
> package are represented in the aggregating package.
> 
> In the IUDD V1, a referenced package was represented by a file element 
> which pointed to its descriptor. We found this problematic, particularly 
> when combined with physical packaging, as it assumed that the descriptor 
> had a fixed relationship relative to the package content.
> 
> In IUDD V2, we changed this so that the aggregating descriptor pointed 
> to the logical root of the referenced package. The package descriptor 
> would be at a well-known location within the referenced package. This 
> allowed us to aggregate packages with existing media (physical) 
> descriptors without having to recreate those media descriptors, but 
> allowing the package descriptors to be copied to a new location (e.g. 
> onto the first CD) for efficiency.
> 
> Anyway, we need to discuss the following regarding aggregating packages:
> 
>     * How is the referenced package represented in the aggregating
>       package descriptor? I'd suggest a file of type "package", which
>       identifies the logical path (i.e. the path that URIs may be
>       relative from). There might also be a good case for this being an
>       extension element, rather than a file element.
>     * Are any files from within the referenced package included in the
>       aggregating package descriptor? I'd suggest not - i.e. inclusion
>       by reference.
> 
> 
> Comments or suggestions? Has anyone in the ACS WG looked at package 
> aggregation scenarios?
> 
> Regards,
> Christine
> 
> Senior Technical Staff Member
> IBM, 11501 Burnet Road, Mail Point 901-6B10
> Austin, TX 78758
> 1-512-838-3482 tl 678-3482
> Inactive hide details for Randy George/Austin/IBM@IBMUSRandy 
> George/Austin/IBM@IBMUS
> 
> 
>                         *Randy George/Austin/IBM@IBMUS*
> 
>                         07/13/2006 09:59 AM
> 
> 	
> 
> To
> 	
> sdd@lists.oasis-open.org
> 
> cc
> 	
> 
> Subject
> 	
> Re: [sdd] Issue 31
> 
> 	
> 
> 
> 
> Another approach might even be simpler. What if we remove the 
> DeploymentDescriptor element from the PackageDescriptor? We have a 
> defined enum value for a File purpose called "deploymentDescriptor". 
> Thus, we can state that to be fully compliant with the SDD 
> specification, a PackageDescriptor MUST contain a File with a 
> purpose="deploymentDescriptor". This element would reference an XML 
> document that is compliant with the deployment descriptor section of 
> this specification.
> 
> Thoughts?
> 
> Regards,
> Randy George
> 
> Senior Technical Staff Member
> Provisioning Architecture
> Tivoli Software, IBM Software Group
> Austin, TX
> (512) 838-0752 T/L 678-0752
> 
> *Julia McCarthy/Raleigh/IBM@IBMUS*
> 
> 07/12/2006 01:46 PM
> 
> 	
> To
> 	
> cc
> 	sdd@lists.oasis-open.org
> Subject
> 	[sdd] Issue 31
> 
> 
> 	
> 
> 
> 
> 
> Issue 31: Is the correspondence between deploymentDescriptor and the 
> file element defining the deployment descriptor simply the fact that the 
> pathname matches? This seems odd. It seems more usual for the 
> deploymentDescriptor to reference the file instead. Currently, the 
> answer is yes - the only correspondence is the matching URI and pathname.
> 
> In researching this, I've discovered that the situation isn't what I 
> thought. In v1 of the iudd schema files had an ID and were referenced 
> with an IDref. Now, files are referenced (at least in artifact elements) 
> by referring to the same URI used in the file element. That is, the URI 
> used in an artifact is simply a pointer to a file element. If the URI in 
> deployment descriptor is intended to be used the same way - as a 
> pointer, then we just need to document this clearly in the 
> deploymentDescriptor element text.
> 
> Here's what the xml would look like for deploymentDescriptor element and 
> the file element for the deployment descriptor.
> <deploymentDescriptor>sdd.xml</deploymentDescriptor>
> 
> <file charEncoding="" compression="false" length="0" pathname="sdd.xml" 
> purpose="deploymentdescriptor">
> 
> <ds:DigestMethod Algorithm="_http://www.ibm.com_ 
> <http://www.ibm.com/>"></ds:DigestMethod>
> <ds:DigestValue>0</ds:DigestValue>
> </file>
> 
> Randy or Christine, can you verify that the intent is for the URI used 
> in deploymentDescriptor to be a pointer to a file element?
> 
> Julia McCarthy
> Tivoli Development
> Deployment Engine Design
> julia@us.ibm.com
> 349/8156
> 877-261-0391
>