Hi William,
Thank you for the review. Comments/questions inline..
On 06/22/10 09:57 AM, William Schumann wrote:
Sarah,
To avoid the all those escaped HTML entities, such as > in the AI
instance document for <manifest_text>, I'd suggest 2 alternatives:
- put the manifest text in a separate document and having only its
pathname or URL in the AI instance document, or
This is a possibility. Referencing the manifest text the same as the
zone configuration data externally might be ok. It would be consistent.
The form of it would have to be the software_spec schema and we could
validate it as well.
- copy the schemas for the different manifest_text DOCTYPEs into the
configuration.dtd. Having multiple copies of schema definitions is a
maintenance hazard long term, but more friendly than requiring the
user to escape the HTML entities properly. Another benefit is that the
manifest_text can be validated along with the AI instance document.
I don't like this really. I think it is messy and as you note a
maintenance hazard.
Consider writing the schema so that required and optional elements of
"slice attribute: action" go with the action, so that the associated
elements are either required, optional, or prohibited based on the
action.
Instead of having this:
slice attribute: action – one of create,delete, preserve, use_existing
slice attribute: name
element: size
size attribute: val – required
size attribute: size-units – required
size attribute: start_sector – optional
do this:
slice attribute: action = create
slice attribute: name - required
element: size
size attribute: val – required
size attribute: size-units – required
size attribute: start_sector – optional
slice attribute: action = delete
slice attribute: name - required
slice attribute: action = use_existing
etc.
The advantage of this method is that DTD validation would then catch
improper usage per action. There would be just a little more code, but
more precise DTD validation.
In DTD we can't associate an attribute with an attribute. It has to be
tied to an element. So, to do what you are suggesting it would look like
this:
<!ELEMENT action (create|delete)>
<!ELEMENT create (size?)>
<ATTLIST create name #REQUIRED>
<!ELEMENT slice(action, size?)>
The xml would look like:
<slice>
<action>
<create name="c1t1d0s0">
<size val=1000 size_units=mb></size>
</action>
</slice>
So, basically I associate attributes with the action, not the target
type. Which again leads to having some attributes associated with the
create that are not appropriate for each target type. The only other way
I could do this is to define the actions to be more specific, that is
something like:
<!ELEMENT action(slice_create|partition_create)>
Then add attributes to each action element. This seems ugly though.
I get why you are asking this, as in some cases, for example, partition
with the delete action, we don't need the part_type for this. And, if
specified it could be at odds with the partition number that the user
has specified. And, the user might get confused about the effect of
using this with a delete.
I can certainly change the schema for say the part_type attribute to
make it optional, and so it doesn't seem to the user that this is
required for all actions. What I am trying to avoid is deep nesting of
the elements just to get to one action, with attributes.
I will look at this a bit more.
thanks,
sarah
***
William
On 06/ 2/10 01:49 AM, Sarah Jelinek wrote:
Hi All,
A redesign effort has been under way for both the AI/DC schemas, and
as a result the manifests themselves. The documents listed below are
the first draft of the redesign proposal.
The documents are located in the caiman-doc repository both the .odt
and .pdf version of the AI/DC Schema and Manifest Redesign document.
You can get the docs here:
ssh://[email protected]/hg/caiman/caiman-docs
by pulling a clone.
I have also posted both versions on the opensolaris.org caiman
project page:
http://hub.opensolaris.org/bin/download/Project+caiman/WebHome/aidcmanifest.odt
http://hub.opensolaris.org/bin/download/Project+caiman/WebHome/aidcmanifest.pdf
Please send your feedback to the alias by 6/22/10.
If you plan to provide a review, please email me privately so I can
keep track of those who want to participate in the review. If you
need more time please let me know when you think you can complete the
review.
As always, thank you for your time and attention.
Regards,
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
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
