Re: [Exist-development] Any feedback on my idea for adding the option of the XML Schema to the xqDoc parameters and return?

[Adam R. <ad...@ex...>]

Rather than refactoring the XML jobs bit, I think some of the output
needs to be refactored. So we should define what a job is and that
should be common between the two, but could contain additional
optional/substituted children for a running job or scheduled job as
appropriate.

On 17 October 2012 21:19, Loren Cahlander <lor...@gm...> wrote:
> I am currently working on the system module and have to create the schema
> for it.  I found a problem with the results from get-running-jobs and
> get-scheduled-jobs.  Both use the root of jobs and then have an element of
> job for each job.  The problem is that the running jobs uses the following
> attributes:
>
> id
> action
> start
> info
>
>
> and the scheduled jobs uses the following attributes:
>
> name
> group
> triggerName
> startTime
> endTime
> fireTime
> nextFireTime
> finalFireTime
> triggerExpression
> triggerState
> running
>
>
> This does not make for a nice XML Schema for the element job.  I am thinking
> that I change the element for scheduled jobs to scheduledJob for a better
> schema.
>
> There is another thing for the addition of the XML Schemas into the xqDoc.
> Can we indicate the root element from the XML Schema in our URI, or do we
> need an additional tag of @root after @schema?
>
> The returned item from each of these calls has the same namespace, but
> different structure.
>
> export
> - collection
> - resource
>
> jobs
> - job
>
> xqueries
> - xquery
>
> ...
>
>
>
> On Oct 16, 2012, at 4:06 PM, Loren Cahlander <lor...@gm...>
> wrote:
>
> I will start a branch off of trunk and start the work then.  Get the java
> function modules with the optional XML Schemas in the signature.
>
> Once I get the mechanism in place, I am hoping that the community can aid in
> making sure that we identify and have the up to date XML Schemas necessary
> for the internal function modules.
>
> On Oct 16, 2012, at 3:56 PM, Wolfgang Meier <wol...@ex...> wrote:
>
> Hi Loren,
>
> I certainly like the idea. The XQuery parser just stores the raw XQDoc
> comment to avoid loosing time during normal compilation. The comment is
> later parsed upon request, so the additional schema field could be extracted
> there and the schema file retrieved.
>
> Wolfgang
>
>
> Am Dienstag, 16. Oktober 2012 um 22:49 schrieb Loren Cahlander:
>
> Hello Wolfgang,
>
> I know that my idea would need to go into a later release, but I would like
> to have your feedback on the idea. I can go through the Java functions to
> add the schema, but need an agreed upon concept for this. It would
> eventually need to be added to the XQuery parser.
>
> Thanks,
> Loren
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> Exist-development mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-development
>



-- 
Adam Retter

eXist Developer
{ United Kingdom }
ad...@ex...
irc://irc.freenode.net/existdb