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...>]

Also... should we actually be changing this XML output? I ask, because
if people are processing it with their apps in XQuery/XSLT then we
will break their existing apps. It might be better just to create a
lax schema that validates the current output?



On 17 October 2012 22:52, Adam Retter <ad...@ex...> wrote:
> 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



-- 
Adam Retter

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