Menu
▾
▴
#27 grammar xsd: merge all valuable from different revisions
Related to https://sourceforge.net/tracker/index.php?func=detail&aid=3052244&group_id=200186&atid=1446552, introduced to continue working at this theme.
Archive of xsd files is here: \documentation\stuff\to check\jpatterns_grammar\
Do not remove this backup folder after finishing working on it, as this could be useful.
In the scope of this task also current xsd grammar is under analysis and some proposal would be introduced (at forum) to make grammar more understandable and easy to use.
Results of my investigations basing on source code and 4 different versions of xsd. Also I have included explanation (e.g. SVN history) on every version of xsd file
1)
what I could change by me and what should be discussed with all the guys?
2)
castor cr
Name N
Value V
Scope S
Priority P
crNVSPPatternBaseType
3)
named
scoped (always priority)
value
base type
groupping patterns
4) it is important to have base type to allow quick extension of framework
castorPatternBaseType
5) from economical point of view usage of one type is better
6) patterns should try to generalize config elements. It is good to consider current code to undestand how it is better to do...
7
0.9.1 very initial version - version of first release
castorNameValueType
castorNameScopePriorityType
do we need both these types if value and scope and priority are optional?
castorParamType
on castorNameValueType
also could need scope and priority?
btw param is optional here too
castorItemType
has all from both castorNameScopePriorityType and castorParamType
name, value, scope, priority and param (castorParamType) inside.
as some element in xml - like item for chain handlers, or item at config or item at factory
so insted of all these 4 types - one type
castorSectionType
could be called castorSectionBaseType
used only as extension base for all sectioned types
castorPatternType?
could castorNameScopePriorityType be used instead
castorGroupType
could be called castorPatternsGroupType, necessary for groups of patterns
allow to include any element based on group
castorMediatorType
castorFactoryType
castorConfigType
JPatternsConfig
make this extendible from groups
71
seems to be last version of 3 years ago development, broke the build as contains some tags not supported by java code.
castorNameValueType
castorNameScopePriorityType
castorParamType
castorPatternScopedItemType
the same as castorItemType except name. Why we introduced new name?
no sense, should be removed
castorPatternType
may be better castorPatternBaseType
castorSectionType
castorPatternsGroupType
the same as castorGroupType above
castorPatternsGroupType_allPatterns
based on castorPatternsGroupType
same as castorGroupType
seems to be it was thought different types of patterns groups could be introduced?
but why to handle this now, when project is not in stable state. It could be added when this is necessary. If architecture is built in a right way - then it would be applied qucikly - new groups etc etc etc
castorFactoryType
castorConfigType
castorMediatorType
JPatternsConfig
97
sergey's fix to allow system working + adding command; almost 7
castorNameValueType
castorNameScopePriorityType
castorParamType
castorPatternScopedItemType
71
castorPatternType
may be better castorPatternBaseType
71
castorSectionType
castorGroupType
castorCommandType
castorCommandTypeType
castorFactoryType
castorConfigType
JPatternsConfig
103
my changes
castorNameValueType
castorNameScopePriorityType
castorParamType
castorPatternScopedItemType
castorPatternType
PatternCommandType
should be removed
castorItemType
castorSectionType
castorCommandType
castorGroupType
castorFactoryType
castorConfigType
JPatternsConfig