Hi Sarah,
My initial impressions. Thank you for sending this out!
On page 7 you mention the differences for an AI/Criteria schema
from a system configuration schema. Due to time constraints I haven't
found time to send out a code review but I've got a fix for Bug
16045 - "SC manifest should not be required to be in an XML
comment when using embedded form" which makes it possible to do:
[snip...]
</ai_uninstall_packages>
<ai_auto_reboot>
false
</ai_auto_reboot>
</ai_manifest>
</ai_embedded_manifest>
<sc_embedded_manifest name="AI">
<service_bundle type="profile" name="name">
<service name="ai_properties" version="1" type="service">
<instance name="default" enabled="true">
<property_group name="ai" type="application">
<propval name="username" type="astring" value="jack"/>
<propval name="userpass" type="astring"
[snip...]
Seamlessly integrating the XML which the publish-manifest application
then validates using RelaxNG and the service_bundle DTD as appropriate,
with no user visable XML differences.
Also on page 9, I'm unable to come up with models which schemas and
DTDs disallow as you say:
Modeling XML trees is very complex and the schema languages themselves
often make a judgment of the goodness of practices in order to limit their
complexity and consequent validation processing times. Such limitations
can reduce the set of possibilities for designing of an XML document.
Do you have an example to broaden my imagination?
I still feel the choice of DTD to be dramatically limiting and not
conducive to leveraging the broader XML community's experience and tools,
seeing that DTD is a document centric schema type and quite antiquated in
teh minds of many opposed to the more data centry schema languages under
active support.
Further, I feel namespaces can help compartmentalize schemas and lacking
them is detriment to a product-wide XML manifest design. Reusable concepts
become fixed to a certain use, or else tag names must disambiguate the
intended use of data (i.e. <target_device> opposed to a general re-usable
<disk> tag inside an install <target> tag (page 30); as the <disk> tag
and associated data could be used in the data-object cache were it
generalized).
Lastly, trying to parse yet another language (DTDs not being XML
themselves) makes it hard to know what's going on. I liked a coworker's
comment to me which was roughly (and the same for me long ago too) DTDs
are what made me think XML sucked years ago; schemas helped me see the
power and usability of XML.
Thank you,
Clay
On Tue, 1 Jun 2010, 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
