This looks like what we agreed on. Thanks for sending this out.
sarah
On 06/ 4/10 08:48 AM, Darren Kenny wrote:
I'd like to summarise some of what we discussed yesterday, and the decisions, or
not, that were made...
- Two sub-trees:
- In general there was acceptance of the need for this
- Q: Why not use two DOC's as opposed to sub-trees?
A: I feel that the need to have two sub-trees is there because
of the way we import XML - we want to only have one registry
of classes, and different applications *may* wish to import into
different sub-trees.
Also, consumers of the API may not care where the data comes
from, so may wish to do something like:
doc.get_descendants(name="object_name", type=MyObject)
which will search both sub-trees without the API consumer needing
to be specific...
This would allow a checkpoint to be unaware of the source of
data - just as long as it exists.
- Taken off-line: Some concerns about use of DOC for checkpoints.
- Converting to XML
- Use of a boolean was accepted as solution
- Type of XML output
- In general acceptance of the use of post-processing of generated DOM
to produce appropriate XML Manifest.
- Q: Does post-processing need to be XSLT, could a Python module be
used instead?
A: While there is nothing to stop you using a Python module to handle
the post-processing, my own personal feelings are that XSLT is
specifically designed to work on XML, and that the use of Python
would be a less-natural fit in this case.
I also think that if the to_xml() methods return XML that matches
the schema, then the actual processing will be minimal, and be
primarily transposing nodes around or selecting specific nodes
of interest for the XML manifest format in question.
- Validation post generation using DTD/Schema was accepted.
- Converting from XML
- Dynamic registration of classes and being done a per-package basis
was accepted - or at least there was no objection.
- Q: Is there really a requirement for addition to XML Manifest?
A: Whether this is necessary or not primarily depends on whether
the XML can be extended by the user - in that they would be
adding new XML tags, and thus need to have the ability to
provide a can_handle implementation.
But, if as the current schema design is stating, checkpoints
will be implemented in XML using generic tags, then there isn't
really any requirement for this, so I'll remove it from the design.
- Does the DataObjectCache need to be singleton?
- We agreed that this may not be necessary, and access to DOC should be via
the Engine, which is itself a singleton.
Did I miss anything?
Thanks,
Darren.
_______________________________________________
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
