I am confused by the statement from Jeroen.
- The default editor presents only elements that are part of the
current XML document, these could indeed be unused and thus invalidate
the metadata. It should not present (unless I'm not aware of this)
optional elements by itself and add them.
I am looking at the current default editor and as well as showing entry
fields for those elements present in the source xml template it also
shows optional metadata fields (with a [+]) for those that are in the
schema.
I would very much like to be able to not have these optional fields
showing on the simpler default editor and only have them on the advanced
editor.
Perhaps I am missing a setting or option that causes the optional fields
not to show on the default editor.
Thanks Andrew
Andrew Watkins
Systems Development Team Manager
National Institute Water & Atmospheric Research (NIWA).
On 9/30/2009 at 3:51 AM, in message
<43149D2E-7387-4D25-8BAA-88FD53C32AF5@anonymised.com>, Jeroen Ticheler
<Jeroen.Ticheler@anonymised.com> wrote:
Hi Stephen,
I discussed this again in more detail with Heikki yesterday and now
think I understand the confusion. I just wanted to once more emphasize
that none of the editors (default nor advanced) to the best of my
knowledge create unasked-for metadata by themselves. Instead:
- The advanced editor presents optional metadata elements without
storing them in the metadata document unless a user clicked on the +
sign next to it. It also presents elements already part of the current
metadata, and these can not be distinguished from the optional ones
not yet present in the metadata.
- The default editor presents only elements that are part of the
current XML document, these could indeed be unused and thus invalidate
the metadata. It should not present (unless I'm not aware of this)
optional elements by itself and add them.
The differences between the two editors allow for the default view to
remain relatively simple, while the advanced editor provides all
flexibility to the user to extend the document according to the XSD
schema.
Now, one thing that could from that perspective be improved is this:
The optional elements that now can only be seen in the advanced view
could also be made visible in the default editor. That visualization
could in fact be optional to avoid all users always see all these
optional elements. I could see this take shape in the form of a CSS
style that can be enabled/disabled within the default editor. As a
consequence we could indeed also prevent ghost elements in the
metadata record, since they are not required anymore to be part of a
template in order to make them visible in the default view.
I hope my attempt to explain this is clear. If you have any questions/
comments I would like to hear them of course.
Ciao,
Jeroen
On Sep 29, 2009, at 11:08 AM, Stephen Poley wrote:
Heikki/Jeroen,
I'm just confirming Heikki's note here. Presenting suggestions is
good; creating unasked-for metadata is not.
Regards,
Stephen
Van: heikki [mailto:tropicano@anonymised.com]
Verzonden: ma 28-9-2009 18:29
Aan: Jeroen Ticheler
CC: Stephen Poley; geonetwork-users@lists.sourceforge.net
Onderwerp: Re: [GeoNetwork-users] Optional non-empty elements - what
do youthink ?
hi Jeroen !
You slightly misrepresented the proposal here: the idea is not to
"remove the suggested elements function" at all. The user would not
be required to start adding elements.
The proposal is that "suggestions" are treated as such, not stored
when the user does not follow up on them. The proposal is *not*
about removing the "suggestions" altogether.
Kind regards
Heikki Doeleman
On Mon, Sep 28, 2009 at 6:21 PM, Jeroen Ticheler
<Jeroen.Ticheler@anonymised.com
> wrote:
Hi Stephen,
I would like to comment on that observation and try to explain the
idea behind the suggested elements:
When you add an element to an ISO me> example, when you add a new contact, the contact itself is only a
parent element with no value in it. It requires a couple of child
elements to be of any use. So what the suggested elements function
does is to add a more complete structure to the metadata document. In
this example it would be the elements for name, address, telephone
number etcetera. Some of these elements indeed are empty but are
required to be filled in when validating metadata.
If you decide to remove the suggested elements function, you require
the user to start adding elements, child elements, child elements of
child elements and so forth by hand. Not only is that much more work,
it also requires that the user has a very deep insight in the XML
structure of the ISO metadata standard. It just makes for a much more
complex editor. Indeed, the user is in full control, but also is
required to know extremely well what to do. In my opinion that is not
the background you can expect the majority of users to have (I myself
would never be able to properly figure out where important metadata
elements are located within the XML structure without studying the XML
Schema or the standard document).
For these reasons I happily defend the existence of the suggested
elements functionality. We have had a concept implementation of XML
sub templates in the past where a user would be able to select from a
couple of different sets of suggested elements. For instance one that
is suitable for vector property descriptions and one for gridded data
descriptions. That would be something I could see to come back in.
Something along those lines is also the already implemented (but to my
knowledge not part of the trunk) function to store spatial reference
systems or contact "sub-templates" in the system and allow the user to
add one of those to a record.
My suggestion to Heikki for the empty elements that cause the metadata
to be invalid is:
Provide the user with a function (through a checkbox for instance)
that would explicitly remove the empty elements that cause the
metadata to be invalid. This checkbox could be an option that is part
of the validation functionality that is already present. It could warn
the user that empty elements will be removed from the metadata upon
execution. The user would now be able to make a deliberate choice to
cleanup and make the record validate.
I consider such an option less intrusive and less of the kind of "We
know what you want" type of behavior compared to an automatic cleanup
procedure.
My 2 cents, ciao,
Jeroen
On Sep 28, 2009, at 10:45 AM, Stephen Poley wrote:
> Lists,
>
> I agree that the editor should not try to second-guess the user. But
> the problem is that this is in fact what the editor is doing *now*,
> and the proposal is actually that this should be removed.
>
> The editor is creating optional elements which the user has not
> asked for, and so is making decisions for the user. And if the
> editor is creating *invalid* metadata which the user has not asked
> for, then it is making pretty poor decisions.
>
> It is a fairly basic UI concept that an application should not have
> an invalid default value for a field (here e.g. empty date) if there
> is a sensible valid default value available (here: whole optional
> section empty).
>
> The proposal is not that something which the user enters be changed
> to something else (as with the notorious Microsoft Word Auto-Corrupt
> function). It is about consistent and user-friendly handling of the
> situation when in a particular section the user enters nothing: in
> that case the editor should create nothing.
>
> Stephen Poley
>
> ________________________________
>
> Van: awalsh [mailto:awalsh@anonymised.com]
> Verzonden: ma 28-9-2009 1:31
> Aan: tropicano@anonymised.com
> CC: geonetwork-users@lists.sourceforge.net;
geonetwork-devel@lists.sourceforge.net
> O> > do youthink ?
>
>
>
> Heikki/List
>
> Yes, this is a tricky problem.
>
> I agree with Francios/Jereon i.e we would guessing about what the
> users wanted. I believe it's up to the
> organisation to have procedures in place to document what elements
> should be entered. Some way to remedy
> this problem is to fill the template optional elements opened with
> sample or dummy values that way you will get less validation
> errors if users forgot to fill in some elements.
>
> Andrew
>
> ----- Original Message -----
> From: "heikki" <tropicano@anonymised.com>
> To: "Geonetwork Users" <geonetwork-users@lists.sourceforge.net>;
<geonetwork-devel@lists.sourceforge.net
> >
> Sent: Friday, September 25, 2009 10:12 PM
> Subject: [GeoNetwork-users] Optional non-empty elements - what do
> you think ?
>
>
>> hello lists,
>> I'd like your opinion about a change proposal suggested by someone
>> in theNGR project.
>> The situation as it is is:
>> 1. a template contains optional elements2. you create a metadata
>> using the template3. the editor presents the optional elements
>> ("suggestions")4. you do not fill out those optional elements5.
>> save the metadata6. the editor saved the optional elements also
>> and voilà, the metadata just saved is invalid, if those optional
>> elements(or some descendant) cannot be empty.
>> Users can only prevent this by actively deleting suggested
>> elements; theproblem with that is, that the vast majority of
elements
>> in e.g. ISO19139 isoptional. The user would spend more time
>> deleting suggestions than actuallyentering metadata content.
>>
>> The poposed change is :
>> Do not save optional elements that cannot be empty and that were
>> left emptyby the user.
>> It should greatly facilitate creating valid metadata using the GN
>> editor. Ofcourse it should not apply to templates, only to
>> metadata.
>>
>>
>> After discussing with Jeroen and Francois, it appears both don't
>> like thischange and they prefer the status quo. As Jeroen feels
>> that if we had thischange, the editor would be making decisions
>> about what the user wants,instead of leaving it up to the user.
>> One could say that that is a matter of perception -- you could also
>> verywell say that the current behaviour to save suggested
>> elements even if theuser did not take up the suggestion, amounts to
>> making decisions for theuser.
>>
>>
>> So I would like to ask everyone, what is your opinion about this ?
>> Kind regardsHeikki Doeleman
>
>
>
>
>
>
------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in
SF, CA
> is the only developer event you need to attend this year. Jumpstart
> your
> developing skills, take BlackBerry mobile applications to market and
> stay
> ahead of the curve. Join us from November 9-12, 2009. Register
> now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> GeoNetwork-users mailing list
> GeoNetwork-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geonetwork-users
> GeoNetwork OpenSource is maintained at
http://sourceforge.net/projects/geonetwork
>
------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart
your
developing skills, take BlackBerry mobile applications to market and
stay
ahead of the curve. Join us from November 9-12, 2009. Register
now!
http://p.sf.net/sfu/devconf
_______________________________________________
GeoNetwork-users mailing list
GeoNetwork-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-users
GeoNetwork OpenSource is maintained at
http://so> 3980 CA Bunnik3981 AJ BunnikE-mail:info@anonymised.com
Tel: +31 30 602 00 70Fax: +31 30 602 00 80KvK/C of C:10148291
ATLIS hanteert een email disclaimer (v1.1) en algemene voorwaarden
voor verkoop (FENIT 2003) en Inkoop (v2.1).
Een kopie is opvraagbaar via 030 6020070 of info@anonymised.com
ATLIS maintains an email disclaimer (v1.1) and general Sales
conditions for sales (FENIT 2003) and Purchasing conditions (v2.1).
A copy can be obtained via +31 30 6020070 or info@anonymised.com
------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and
stay
ahead of the curve. Join us from November 9-12, 2009. Register
now!
http://p.sf.net/sfu/devconf
_______________________________________________
GeoNetwork-users mailing list
GeoNetwork-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-users
GeoNetwork OpenSource is maintained at
http://sourceforge.net/projects/geonetwork
NIWA is the trading name of the National Institute of Water &
Atmospheric Research Ltd.