Aliases for schema file paths
When developing on different branches it is not so straightforward to call diamond invoking the relevant schema file (i.e. the -s option is required with a full path to the project schema file).
How about the function to give schema files aliases, much like the aliases in hg for pull and push servers - see http://
# diamond -s $HOME/cur/
could be replaced by
# diamond -s iceshelf
(possibly using -s with a sanity check, such as if the argument doesn't contain /\.rng$/ or even /\//, then it is an alias)
The schemata files would contain a list of the aliases, and a default, e.g ~/.diamond/
fluidity markup language
default = $HOME/cur/
iceshelf = $HOME/cur/
release = $HOME/fluidity/
world_domination = /home/pinkyandt
To maintain compatibility with the current schema files, a second line without /^default *=/ could be assumed as the default, and since lines after the second are not considered by the current diamond code, there would be no problem interpreting legacy schemata files.
Could this also be added as an option in the flml file, i.e. the option to specify an alias to a schema file. In the case above, this might be:
<schema_alias>
<string_
</schema_alias>
When the file is opened in diamond with:
# diamond file.flml
the schema path linked with the alias is looked up and used to read the fluidity option tree. If the alias doesn't exist, it just uses the default, which is what it would do currently. If a schema path or alias is provided as an argument, this overrides the option in the file.
Blueprint information
- Status:
- Started
- Approver:
- None
- Priority:
- Undefined
- Drafter:
- Adam Candy
- Direction:
- Needs approval
- Assignee:
- Fraser Waters
- Definition:
- New
- Series goal:
- None
- Implementation:
-
Beta Available
- Milestone target:
- None
- Started by
- Fraser Waters
- Completed by
Whiteboard
We didn't put schema references in the xml when we first designed Spud because there wasn't a standard way of doing it. It looks like w3c fixed this last year:
http://
I suggest we should try to follow the standard on this.
--
Schema references in the xml are a bonus in this blueprint. We should maybe submit this part as a separate blueprint, as it is a lot less clear how to implement.
--
This schema-
https:/
--
My opinion is that if it's possible to do the second part an "official" way then that would be preferable to adding another suggested absolute path to the schema. I realise this one wouldn't be required but it's already quite annoying to incorporate /geometry/dimension into every schema.
Could a more local, hacked up version of the first bit not be done through your own environment variables?
There is a related blueprint, which Stephan put together some time ago, for managing different schemas a little more cleanly at:
https:/
- Cian
(lamenting the lack of a proper comments section on lp blueprints)
--
A hack? Cian, you surprise me! Sure a hacked up version of aliases can be implemented, I already have something working quite nicely already, but it is just a hack, and why not add this functionality to diamond, and make it available by default?
I originally posted the above on Stephan's blueprint, but decided it was of a significant difference that warranted its own case. Personally, I'd find this more useful, but I can see that his suggestion would make diamond more friendly for new users (and those who like clicking buttons on menus). The defined aliases could be available in the diamond menu, as Stephen describes in the blueprint.
--
For anyone who'll find this useful, here's the wrapper I have for this: - please use and add thoughts on this proposal here.
#!/bin/bash
# asc
# Usage $0 (alias) ...usual diamond fluff...
# Usage $0 -a (alias) ...usual diamond fluff...
# For completion, add the following to spud/diamond/
# -a)
# cur=${COMP_
# COMPREPLY=( $(compgen -W "$(if test -e "${HOME}
# return 0
# ;;
if [ -e "${HOME}
diamond=
else
diamond=diamond
fi
parse()
{
parseinternal()
{
path=$(grep "^${1} " ${HOME}
if [ $(echo "$path" | wc -l) -gt 1 ]; then echo "Ambiguous, multiple matches."; exit 1;
elif [ $(echo "$path" | wc -c) -gt 1 ]; then
#if [ -e "$path" ]; then
return 0
#else
# echo "Alias found, but path not present: $path"
# path=""; return 1;
#fi
else path=""; return 1;
fi
}
parseinternal $1
if [ $? -ne 0 ]; then echo "No match found, using default"; parseinternal default; fi
}
if [ $# -gt 0 ] \
&& echo "$1" | grep -v -q '^-' \
&& echo "$1" | grep -v -q '\.flml$'; then
parse $1
shift
elif [ $# -gt 1 ] \
&& [ "$1" == "-a" ] \
&& echo "$2" | grep -v -q '^-' \
&& echo "$2" | grep -v -q '\.flml$'; then
shift
parse $1
shift
fi
eval $diamond $(if [ "$path" != "" ]; then echo "-s"; fi) "$path" $@
--
[fwaters] The first half of this (changing config files) is done. The second half about adding references in the XML needs more design.
[pef] I don't think putting references in the XML will ever happen. Either the element that contains it lives in the schema, or it doesn't. If it doesn't live in the schema, then diamond is producing invalid output files. If it does live in the schema, then the user will see it in diamond and be confused. And if we put it in one of the header elements -- what should diamond do with it, anyway? What if one user writes the flml with a schema on his machine, and another user opens it, and that schema doesn't exist? The system at the minute isn't perfect if
you have a lot of branches and a lot of different schemas, but at least users of diamond know exactly which schema they are opening an flml with -- the one the user told diamond to use.
[dham] I don't think this logic follows. There are definitely sensible things that diamond can do with schema information embedded in the file. A sensible policy might be, for example, that the schema used is:
1. that specified on the command line
2. that specified in the file
3. that specified in ~/.diamond
Diamond could also warn the user if there is a mismatch between any of these.
As for the invalid point: well that would be the point of following the w3c recommendation and putting it in a processing instruction.
[skramer] The problem with specifying anything in the XML, is that you would constantly have to "port" flmls between schemas of different branches. The problem we're dealing with here is developers having over a dozen or so different branches lying around, each implementing a new feature and the developer has some flml, either from a local problem setup or from a test (from trunk or a random other branch) and they want to try out/test a feature from one of these branches. In such a case it will always have to be a choice by the developer which schema is used to open the flml with. Even having a specification that refers to schemas from launchpad branches won't do, as in the end of the day it's still a schema from a local copy of such a branch (and a specific revision) that you want to use, and you may have multiple checkouts of said branch.
I think that usage case is nicely dealt with with the aliases above and these aliases make much more sense as a developer-specific configuration, i.e. each developer chooses his own aliases depending on whatever branches he has. It's in the very nature of dvcs that development branches (and therefore the associated schemas) are fluid and therefore developer specific.
I realize that none of this negates the possibility of having the 3-point fall-back mechanism dham outlined above. But I just don't see the use for point 2, specifying it in the xml options file. In my opinion, that would only make sense for a long-lived branch that has some sort of canonical status on its own, say for instance the "stable" branch vs. the trunk. But then you still would have the problem of porting flmls between the two.
(this whiteboard feature is indeed a pain in the neck btw)
