Sarah,
Still on target.dtd:
element <snapshot>, a sub-element of <dataset> is not declared anywhere.
I presume it should be?
Also, your DC example manifest, dc_livecd_derfault.xml, does not validate.
I think some of the <compression> and <boot_archive> elements are in the
wrong place?
- Dermot
On 07/05/10 19:02, Dermot McCluskey wrote:
Hi Sarah,
Regarding the following line in target.dtd:
<!ATTLIST target_device keyword (boot_disk) "boot_disk">
Does this imply there is only one allowed value for keyword, which
is "boot_disk", and that this is also the default value? If so, what
is the
point of this attribute? Once we load defaults (eg "xmllint --dtdattr")
then target_device will *always* have a keyword attribute whose value
is "boot_disk".
Also, regarding this line:
<!ELEMENT disk ((disk_name|disk_prop|disk_keyword)*, partition*,
slice*)>
what is the "(disk_name|disk_prop|disk_keyword)*" portion saying? I
think
it says you can have any *one* of those 3 sub-elements, but you can
repeat
the choice multiple times, thereby allowing you to have all 3 or any
combination thereof. If those 3 elements are mutually exclusive (?),
but also
optional, then perhaps you should have:
<!ELEMENT disk ((disk_name|disk_prop|disk_keyword)?, partition*,
slice*)>
Also, there now appear to be two separate ways to specify that the
"boot_disk"
is to be the install target:
<target>
<target_device keyword="boot_disk"/>
</target>
or
<target>
<target_device>
<disk>
<disk_keyword key="boot_disk"/>
</disk>
</target>
</target>
Is that intended?
- Dermot
On 07/03/10 00:12, Sarah Jelinek wrote:
Hi All,
I updated the AI/DC schemas and the design document to reflect the
comments received in the initial design review. If you want to see
the specific changes, please use the .odt file and set the show
changes and you will see the edits.
The areas I modified were:
-Target dtd. This is based on feedback plus discussions about the use
cases for AI. You will see a high level disk object now, that
encapsulates the partitions, slices or other parts. The new AI schema
supports mutliple disks and pools. And, the associated components.
-Execution dtd. We are no longer embedded software in the checkpoint
elements. The software spec now has a name which much match the
checkpoint name to differentiate different software data for multiple
transfer checkpoints.
-Software spec dtd. This now has elements and attributes for facets,
and better publisher/origin definition.
-I removed the extraneous definitions that were in text for each of
the schemas. The schemas themselves should be sufficient.
-I added the dtd's as well as example instance documents to the gate
for reference.
Please review and send comments. I would like to close this out by
COB 7/9/10.
Thank you,
sarah
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
