On 06/ 3/10 04:18 PM, [email protected] wrote:
Hi Sarah,
My initial impressions. Thank you for sending this out!
Hi Clay,
Thank you for the review. My comments inline...
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.
The plan for Jan's work is that we won't be inlining the actual XML for
the SC stuff. At least at this point in time, that is my understanding
of the current plan. The idea behind the configuration section of the
schema I am proposing in this document, which currently includes the SC
stuff, is that we can specify the validation methods, and additional
input as optional.
Having this inline, or not, as you suggest, still means we are using the
DTD as the schema for the SC portion of the manifest, and the idea is
that we use the same schema language for all the installer pieces. You
solution certainly solves the XML portion of it, but the schema we are
using for SC is still DTD. My argument of using different schemas which
I am trying to resolve, even with your solution, is still valid. Also, I
would not proceed forward with your fix as Jan, Ethan, William and I are
working on a different way to provide the SC portion of the manifest in
AI. Even if what I am proposing in my design document doesn't hold up,
your solution has to be coordinated with the larger SC effort.
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 think this is just a general comment about using any XML schema.
Enforcing a form in a schema limits the user to being able to express
things in their XML trees to the schema definition. Modeling data in XML
is complex, and having a schema written by another person, may not be
sufficient in terms of what a user may or may not want.
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.
I disagree. If I thought DTD was that difficult to use, or in any way
limited us with our ability to provide a user with the appropriate AI
interface I wouldn't have chosen it, even if it met all the
requirements. It isn't antiquated, as you noted in a previous email,
there are proposed changes in the pipe for DTD, so it is obviously not
dead. If you can point out why it will fail to work for our
applications, feel free, but just telling me you don't like it isn't a
valid review comment.
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).
DTD allows us to compartmentalize schemas as well, as you can see in my
design. I have multiple schema files, and only use those in the AI and
DC schemas as required. By including them as required. This allows the
full flexibility we need, and in my opinion is much easier to understand
than using namespaces. My design has reusable components. If a change is
made to a common schema, then we include that new schema, which is
essentially a new namespace. If the way I have designed the schemas, as
you note above, using the target_device tag, as opposed to the disk tag,
inside an install target tag, then point that out. Or, if I can
compartmentalize the schemas in a way that makes them more usable,
please provide data about this. If you want to reuse the 'disk' tag,
then maybe I need to put it in a common schema, and use the install
target in the larger schema, say AI. I am open to this type of
suggestion. I don't think DTD limits us from doing this.
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.
Most people don't look at the schema itself. They look at the XML
instance document for examples. The schemas we currently have are very
difficult to understand, imo, and they are in XML. So, it isn't XML that
makes it easy, it is format required to define the data in XML that
makes it user friendly.
thanks,
sarah
****
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
