Re: [basex-talk] Value out of range on xs:integer?

. From: Christian Grün Sent: Tuesday, July 26, 2016 1:41 AM To: Jorge Williams Cc: BaseX Subject: Re: [basex-talk] Value out of range on xs:integer? Hi Jorge, The XQuery spec allows implementations to limit the range of integers. We have set this limit to 2^64, as it turns out

[basex-talk] Value out of range on xs:integer?

Hello all, Performing this query... xquery version "1.0"; declare namespace tst="http://test.racspace.com";; declare function tst:factorial ($input as xs:integer) as xs:integer { let $result := tst:multiply(1 to $input) return $result }; declare function tst:multiply ($inputs as xs:i

Re: Interaction between redefine+include breaks augmenting a base schema's element with new attributes

erested in reviewing Sam's fork directly and then merging from there? Thanks, -jOrGe W. From: Mukul Gandhi Sent: Tuesday, June 28, 2016 12:15 AM To: Jorge Williams Cc: j-users@xerces.apache.org; s...@tunnelvisionlabs.com; Michael Glavassevich Subject: Re

Re: Interaction between redefine+include breaks augmenting a base schema's element with new attributes

pecification. On 24 June 2016 at 02:49, Jorge Williams mailto:jorge.willi...@rackspace.com>> wrote: Hey Guys, If we are planning a release of Xerces, may I suggest that we also update version of PsycoPath that Xerces is currently using. The current version of the XPath 2 implementation r

Re: Interaction between redefine+include breaks augmenting a base schema's element with new attributes

Hey Guys, If we are planning a release of Xerces, may I suggest that we also update version of PsycoPath that Xerces is currently using. The current version of the XPath 2 implementation reports over 800 failures in the W3C test suite. Sam Harwell has been able to reduce this number to about

Psychopath source??

Hello, In the XML schema 1.1 branch you are including a jar for the PsycoPathXPath processor in the tools directory. I know you’ve included a number of fixes to that code base (XERCESJ-1608, for example), can you please point me to the source code that you use to build that jar? Thank you,

Re: RESTful, WSDL 2.0 & WADL

We use WADL a lot at Rackspace for documentation and validation. Description languages are good when you want to automate. We have dozens of complex internal services which we need to precisely document, validate, translate, etc. Doing this manually would take a fair amount of effort and would

Re: [openstack-dev] [Keystone] V3 Extensions Discoverability

On Aug 6, 2013, at 12:34 PM, Jay Pipes wrote: > On 08/06/2013 01:21 PM, David Chadwick wrote: >> >> >> On 06/08/2013 18:11, Jay Pipes wrote: >>> What SMTP, DNS and LDAP extensions are in use by systems that need to >>> interoperate in the same way that Keystone does? <-- This is a genuine >>> q

Re: [openstack-dev] [Keystone] V3 Extensions Discoverability

On Aug 6, 2013, at 8:36 AM, Adam Young wrote: > On 08/06/2013 01:19 AM, Jamie Lennox wrote: >> Hi all, >> >> Partially in response to the trusts API review in keystoneclient >> (https://review.openstack.org/#/c/39899/ ) and my work on keystone API >> version discoverability (spell-check disagree

Re: [openstack-dev] XML Support for Nova v3 API

m jsonschema and some method > for prettifying the xml representation via jsonschema tags. The jsonschema + > tags approach is probably a bit further off (maybe for v4?), so having an > auto conversion which is ugly but functional seems better than no XML support > at all. &

Re: [openstack-dev] XML Support for Nova v3 API

On Jun 20, 2013, at 10:51 AM, Russell Bryant wrote: > On 06/20/2013 11:20 AM, Brian Elliott wrote: >> On Jun 19, 2013, at 7:34 PM, Christopher Yeoh wrote: >> >>> Hi, >>> >>> Just wondering what people thought about how necessary it is to keep XML >>> support for the Nova v3 API, given that if

Re: [openstack-dev] XML Support for Nova v3 API

There was a presentation by Pete Johnson in the San Diego summit about what we're missing in OpenStack for enterprises and good support for XML was on the list: http://www.openstack.org/summit/san-diego-2012/openstack-summit-sessions/presentation/enterprise-to-openstack-here-s-what-you-re-missi

Re: [Openstack] [Doc] Talk shop: API Docs

We are outside by the bell at the top of the stairs. Sent from my Motorola Smartphone on the Now Network from Sprint! -Original message- From: thingee To: Anne Gentle Cc: "openstack@lists.launchpad.net" Sent: Tue, Apr 16, 2013 15:23:37 PDT Subject: Re: [Openstack] [Doc] Talk shop: API

Re: Trouble compiling XSD 1.1 branch

Ah looks, like I need to just do ./build.sh clean jars right? On Mar 4, 2013, at 3:30 PM, Jorge Williams wrote: > Hey guys, > > I'm on the latest xml-schema-1.1-dev branch in SVN. Trying to compile with > > ./build.sh clean jars-schema11 > > I'm getting al

Trouble compiling XSD 1.1 branch

Hey guys, I'm on the latest xml-schema-1.1-dev branch in SVN. Trying to compile with ./build.sh clean jars-schema11 I'm getting all sorts of errors: compile-schema11: [copy] Copying 23 files to /Users/jorgew/projects/xercesj/build/classes [xjavac] Compiling 776 source files to /Users/

Re: [Openstack] Do we have any schema for keystone v3.0 request/responses

I was waiting for things to stabilize. Give me the go ahead Joe and I'll update and submit. Sent from my Motorola Smartphone on the Now Network from Sprint! -Original message- From: heckj To: "Ali, Haneef" Cc: "openstack@lists.launchpad.net" Sent: Wed, Dec 5, 2012 18:32:03 CST Subjec

Re: [Openstack] [openstack-dev] Fwd: [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API

need the server to do that additional validation for you. Right. -Dolph On Thu, Nov 15, 2012 at 8:20 AM, Jorge Williams mailto:jorge.willi...@rackspace.com>> wrote: No, it's optional. Token validation returns what it normally does. The only thing belongs to does is that you fai

Re: [Openstack] [openstack-dev] Fwd: [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API

mandatory? If not, what will token validation API return? > > {"access": [list of tokens]} > > ? > > > Guang > > > -Original Message- > From: Jorge Williams [mailto:jorge.willi...@rackspace.com] > Sent: Wednesday, November 14, 2012

Re: [Openstack] [openstack-dev] Fwd: [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API

t;> >>> Thanks, >>> joe >>> >>> -----Original Message- >>> From: openstack-bounces+joe.savak=rackspace@lists.launchpad.net >>> [mailto:openstack-bounces+joe.savak=rackspace@lists.launchpad.net] On >>> Behalf Of heckj >&

Re: [Openstack] [openstack-dev] Fwd: [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API

t; unscoped token? Surely they will have the same scope won't they? In >>>>> which case there is no need for both concepts. >>>> >>>> let's compare with Kerberos: In my view an unscoped token is >>>> comparaable with a ticket granting

Re: [Openstack] Fwd: [openstack-dev] [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API

I'm okay with "Starting Tokens". -jOrGe W. On Oct 23, 2012, at 7:25 AM, Adam Young wrote: On 10/23/2012 01:25 AM, Jorge Williams wrote: Here's my view: On making the default token a configuration option: Like the idea. Disabling the option by default. That's fine

Re: [Openstack] Fwd: [openstack-dev] [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API

Are you guys +1 ing the original Idea, my suggestion to make it optional, the fact that I think we should call these sloppy tokens? On 10/22/2012 03:40 PM, Jorge Williams wrote: +1 here too. At the end of the day, we'd like the identity API to be flexible enough to allow the token to be

Re: [Openstack] Fwd: [openstack-dev] [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API

+1 here too. At the end of the day, we'd like the identity API to be flexible enough to allow the token to be scoped in a manner that the deployer sees fit. What the keystone implementation does by default is a different matter -- and disabling multiple tenant scope by default would be fine b

Re: [Openstack] [keystone] Rate limit middleware

More info on the Repose rate limiter here: http://wiki.openrepose.org/display/REPOSE/Rate+Limiting+Filter The rate limiter has the concept of limit groups -- you can specify rate limits for a particular group -- then introspect the request to see which group applies. Typically a user can be pl

Re: Weird XSD 1.1 assertion error

nd define a suitable error handler as following, > > class ErrHandler implements ErrorHandler { >... > } > > On Fri, Jun 22, 2012 at 12:48 AM, Jorge Williams > wrote: >> Hey Guys, >> >> Can you give me a hand. I'm getting a weird error that I cannot rep

Weird XSD 1.1 assertion error

Hey Guys, Can you give me a hand. I'm getting a weird error that I cannot replicate with jaxp.SourceValidator so I know I must be doing something wrong, but I can't tell what. My code looks like this: package com.rackspace.xerces; import javax.xml.validation.*; import javax.xml.transform.str

Re: Issue with XSD 1.1 assertions with dateTime and duration...

Just got around to testing. Works! Thank you, -jOrGe W On Jun 16, 2012, at 3:37 AM, Mukul Gandhi wrote: > Hi Jorge, > The fixes for this issue are now available on SVN (revision, > 1350884). You may verify as appropriate. > > On Fri, Jun 15, 2012 at 4:56 PM, Jorge Wi

Re: [Openstack] WADL [was: v3 API draft (update and questions to the community)]

All of the XSDs produced so far use XSD 1.1. -jOrGe W. On Jun 15, 2012, at 8:57 AM, Christopher B Ferris wrote: +1 Over-reliance on WADL will only make it more challenging to gracefully evolve the APIs such that implementations can be forwards and/or backwards compatible, especially when exc

Re: [Openstack] WADL [was: v3 API draft (update and questions to the community)]

Totally agree. Note that we are using WADL today to create documentation artifacts. So http://api.openstack.org/ is generated from WADLs as are good chunks of the books on http://docs.openstack.org/. We're also using WADL for validation and testing at Rackspace internally, and I'm sure othe

Re: Issue with XSD 1.1 assertions with dateTime and duration...

(Inline) On Jun 15, 2012, at 1:08 AM, Mukul Gandhi wrote: > Hi Jorge, > > On Thu, Jun 14, 2012 at 5:44 PM, Jorge Williams > wrote: > >> I couldn't find anything in the standard that says that implementation must >> have typed nodes > > The XSD 1.1 asse

Re: Issue with XSD 1.1 assertions with dateTime and duration...

There is a case where handling the cast correctly is critically important: when you are dealing with an implementation where nodes are not typed. In this case, you *always* have to do a cast to inform the validator of the type of a particular value. The Saxon implementation works this way, a

Re: [Netstack] About API v2.0 return value by list_xx

e pagination > is trivial. > > - Peter > >> From: Joseph Heck >> Date: Sun, Jun 10, 2012 at 2:08 PM >> Subject: Re: [Netstack] About API v2.0 return value by list_xx >> To: Yong Sheng Gong >> Cc: netstack@lists.launchpad.net, Jason Kölker , Jorge >> Wil

Re: [Netstack] About API v2.0 return value by list_xx

There are no formal style guidelines, but collection in compute follow the format that you labeled 1.1 below...this is also done by keystone, lbaas and others, so I think that's what you should follow. I also think that you should make sure that you allow for pagination as described here: http

Re: [Openstack] Nova API Specification

On May 30, 2012, at 8:33 AM, Day, Phil wrote: Hi Folks, I was looking for the full definition of the API requests, and I’m a tad confused by what I find here: http://api.openstack.org/ Specifically for Server Create there is both and “Server – Create” and “Server – Extended Create”, although

Re: [Openstack] Keystone service catalogue has non-core services?

Hey Liem, We had a brief conversation about this at the summit. Ec2 and volume are core services not extension services -- this was described in a wiki somewhere. Carlos has gone through the contracts cleaned them up and updated them to reflect reality -- and they include this particular cha

Re: Issue with XSD 1.1 assertions with dateTime and duration...

Hey Guys, Seems like the last couple of bugs relate to the XPath 2 engine specifically. If PsycoPath claims full conformance, then the deficiencies are really in the XPath 2 test suite. -jOrGe W. On May 24, 2012, at 4:10 PM, Mukul Gandhi wrote: > Hi Michael, >I believe, the W3C's XML Sc

Re: Issue with XSD 1.1 assertions with dateTime and duration...

On May 24, 2012, at 3:45 PM, Mukul Gandhi wrote: Thanks, Jorge for bringing these issues to the list :) No problem. Thanks for addressing these issues so quickly! -jOrGe W.

Re: Issue with XSD 1.1 assertions with dateTime and duration...

, we don't need to explicitly > cast them during XPath expression evaluation. > > > On Tue, May 22, 2012 at 11:30 PM, Jorge Williams > wrote: >> Hi Mukul, >> >> Just updated. Unfortunately, I'm still getting the same error with the >> same examp

Re: Issue with XSD 1.1 assertions with dateTime and duration...

feel free to report, if you find anything still incorrect. > > > On Fri, May 18, 2012 at 5:06 AM, Jorge Williams > wrote: >> >> On May 17, 2012, at 2:56 PM, Mukul Gandhi wrote: >> >>> Hi Jorge, >>> With my quick analysis of your use-case, I can co

Re: Issue with XSD 1.1 assertions with dateTime and duration...

On May 17, 2012, at 2:56 PM, Mukul Gandhi wrote: > Hi Jorge, > With my quick analysis of your use-case, I can conclude that this > may be a possible bug (and quite likely in our XSD 1.1 XPath2 engine). > > As a workaround, I can find the following expression to be working > correctly though, >

Issue with XSD 1.1 assertions with dateTime and duration...

Hey Guys, I'm working off of the latest 1.1 branch. I have the following schema: http://www.w3.org/2001/XMLSchema"; xmlns:xsd="http://www.w3.org/2001/XMLSchema"; xmlns:tst="http://www.rackspace.com/test/simple"; targetNamespace="http://www.rackspace.com/test/simple";>

Re: [Openstack] Just JSON, and extensibility

On Apr 13, 2012, at 3:20 PM, Justin Santa Barbara wrote: My understanding is that the solution we have now is that any extension goes into its own namespace; we assign a prefix to the namespace and have a way to map that prefix to the full namespace. (Similar to XML schemas). Currently prefi

Re: [Openstack] Just JSON, and extensibility

On Apr 13, 2012, at 8:47 AM, Mark Nottingham wrote: > [ Full disclosure -- I'm using my personal address with Launchpad, etc., but > I work for Rackspace. ] > > On 12/04/2012, at 7:28 PM, Jorge Williams wrote: > >> Generally, I agree with a lot of what you're

Re: [Openstack] Image API v2 Draft 4

Generally, I agree with a lot of what you're saying, but I want to point out a couple of things: 1. Static language folks gravitate to XML, not simply because they're invested in it, but because it solves a real problem: In a static language, I want to to say something like: myServer.name = "

Re: [Openstack] Image API v2 Draft 4

I'm also a strong supporter of XML. XML does a good job of lowering barriers for a key group of clients, specifically those that work with statically typed languages. It offers key benefits in terms of extensibility and validation. I'd hate to lose it. -jOrGe W. On Apr 10, 2012, at 12:57 PM,

Re: [Openstack] Image API v2 Draft 4

On Apr 9, 2012, at 6:03 PM, Justin Santa Barbara wrote: How about we discuss this further at the summit :-) I think that's a sensible proposal. We're not likely to reach a good conclusion here. I think my viewpoint is that even json-dressed-as-xml is fine; no end-user gives two hoots what ou

Re: [Openstack] Image API v2 Draft 4

Justin, >From a JAX-RS / Java persecutive, starting with an XML schema and having that >dictate what the JSON will look like -- doesn't just make sense -- it makes >life *A LOT* easier. And a lot of services written in Java do just that. >Unfortunately, as you pointed out, this approach has

Re: Error with simple type assertions and xsi:type

nteger" via xsi:type) > > I therefore do not think, that xs:assertion within xs:simpleType works > incorrectly, when such a type is selected via xsi:type from an XML > instance document. > > I'm currently not sure, whether the observation you've shared may be a > po

Re: Error with simple type assertions and xsi:type

hmm..attachments didn't seem to go through? On Apr 2, 2012, at 4:38 PM, Jorge Williams wrote: Hello again, found another potential bug: In the latest XSD 1.1 branch, it looks like simple type assertions are not being enforced when the type is specified via the xsi:type attribute.

Error with simple type assertions and xsi:type

Hello again, found another potential bug: In the latest XSD 1.1 branch, it looks like simple type assertions are not being enforced when the type is specified via the xsi:type attribute. I'm attaching a schema and instance documents as a reference. If I do java -cp $CLASSPATH jaxp.SourceVa

Re: NPE while playing with CTA in XSD 1.1 branch

Looks good. Thank you, jOrGe W. On Mar 31, 2012, at 7:24 AM, Mukul Gandhi wrote: > Hi Jorge, > Thanks very much for reporting this error. > > This has now been fixed in SVN. You may verify the fix. > > On Mon, Mar 26, 2012 at 7:47 PM, Jorge Williams > wro

Re: NPE while playing with CTA in XSD 1.1 branch

te: > >> Hi Jorge, >> It seems you've found a NPE bug. It's now fixed in SVN. >> >> Could you please verify the fix. >> >> On Thu, Mar 22, 2012 at 2:58 PM, Jorge Williams >> wrote: >>> >>> Hi all, >>> &

Re: NPE while playing with CTA in XSD 1.1 branch

Just got around to testing it. Looks good. Thanks, -jOrGe W. On Mar 23, 2012, at 3:02 AM, Mukul Gandhi wrote: > Hi Jorge, > It seems you've found a NPE bug. It's now fixed in SVN. > > Could you please verify the fix. > > On Thu, Mar 22, 2012 at 2:58

NPE while playing with CTA in XSD 1.1 branch

Hi all, I've been playing around with the latest XSD 1.1 branch and ran into the following. I'm attaching a schema and instance documents as a reference. If I do java -cp $CLASSPATH jaxp.SourceValidator -fx -xsd11 -a usage.xsd -i sample.xml or java -cp $CLASSPATH jaxp.SourceValidator -f

Problem building xml-schema-1.1-dev

The following seems to fix: diff --git a/samples/xs/XSSerializer.java b/samples/xs/XSSerializer.java index 400d28b..bdf1b6b 100644 --- a/samples/xs/XSSerializer.java +++ b/samples/xs/XSSerializer.java @@ -39,7 +39,7 @@ import org.apache.xerces.impl.xs.identity.Field; import org.apache.xerces.impl

Re: Errors encountered while playing with CTA in XSD 1.1 branch

e paths in PsychoPath engine, then users would have to report such > cases on the list or in a bug report, and we'll have to solve (or keep > unsolved if there's failure risk in other parts of PsychoPath XPath > engine) each such report on a case by case basis. > >

Re: [Openstack] OpenStack Java API

Some thoughts, Using the binding to generate WADLs and XSDs would definitely be useful -- especially since a lot of the extensions are currently undocumented. Certainly we can use these as a starting point for our documentation efforts. Keep in mind, though, that extensions are optional and th

Errors encountered while playing with CTA in XSD 1.1 branch

Hi all, I've been playing around with the latest XSD 1.1 branch and ran into the following. I'm attaching a schema and instance document as a reference. The first error deals with an assertion going off somewhere out in the XPath 2 implementation. If I do: java -cp $CLASSPATH jaxp.SourceV

Re: [Openstack] Keystone: is revoke token API "officially" supported

ws mailto:dolph.math...@gmail.com>> Date: Thu, 26 Jan 2012 17:17:12 -0600 To: Ziad Sawalha mailto:ziad.sawa...@rackspace.com>> Cc: Jorge Williams mailto:jorge.willi...@rackspace.com>>, Dolph Mathews mailto:dolph.math...@gmail.com>>, "Yee, Guang" mailto:guang@hp.c

Re: [Openstack] Keystone: is revoke token API "officially" supported

nly be adding a new method on an existing resource, so would not require complex naming changes… Open to alternative points of view.. Z From: Jorge Williams mailto:jorge.willi...@rackspace.com>> Date: Thu, 26 Jan 2012 13:36:13 -0600 To: Dolph Mathews mailto:dolph.math...@gmail.com>>

Re: [Openstack] Keystone: is revoke token API "officially" supported

xtension like this. I'd still lean towards the "correct" practice of adding this as another extension. Especially since that extension would only be adding a new method on an existing resource, so would not require complex naming changes… Open to alternative poin

Re: [Openstack] Keystone: is revoke token API "officially" supported

Moving it to an extension makes sense to me. Ziad, does it make sense to add it to OS-KSADM...or is this a different extension all together...revoke token extension? -jOrGe W. On Jan 26, 2012, at 11:43 AM, Dolph Mathews wrote: It is definitely not a documented call (hence the "should this be

Re: [Openstack] WADL for compute API v1.1

I don't think that it would be too nasty given the way that Anne has structured: https://github.com/openstack/compute-api Where we have a different directory for each version of the API. -jOrGe W. On Jan 25, 2012, at 10:30 AM, Eoghan Glynn wrote: > > >> So I was wondering whether there was a

Re: [Openstack] WADL for compute API v1.1

They should point to the correct links. I believe that the PDFs and WADL are published on docs.openstack.org, and the links should point to the artifacts there. Or you can do what keystone is doing and host the stuff locally. -jOrGe W. On Jan 25, 2012, at 10:08 AM, Eoghan Glynn wrote: > >

Re: [Openstack] Supporting start/stop compute api from OpenStack API

Tomoe, Once you get the extension up and running you'd want to document it :-) There are a set of templates for documenting the extension here: https://github.com/RackerWilliams/extension-doc-templates More (high level) details on API extensions here: http://docs.rackspace.com/openstack-extens

Re: [Openstack] Configure Rate limits on OS API

Hi Blake, Repose is capable of rate limiting based on group. It also supports querying limits and maintaining the limits consistent even as nodes are scaled horizontally. You can find the code on git hub: https://github.com/rackspace/repose Here's the presentation I gave on the subject on Es

Re: [Openstack] Automatically confirmed after 24 hours on Resize API

I'm with Waldon on this. This is a spec...the implementation hasnt caught up. Sent from my Motorola Smartphone on the Now Network from Sprint! -Original message- From: Brian Waldon To: Anne Gentle Cc: "openstack@lists.launchpad.net" Sent: Tue, Dec 27, 2011 10:20:30 CST Subject: Re:

Re: [Openstack] Extension Documentation

for integration are >>> welcomed. >>> 8. We need a discussion about who will review these extension >>> submissions and ensure they get built. >>> >>> Based on the struggle to get these docs written, I also want to know >>> if you all find the t

Re: [Openstack] Extension Documentation

Inline: -Original Message- From: Anne Gentle Date: Fri, 9 Dec 2011 08:17:15 -0600 To: Jorge Williams Cc: "openstack@lists.launchpad.net (openstack@lists.launchpad.net)" Subject: Re: [Openstack] Extension Documentation >Hi everyone - >Overall I support this effort and h

Re: [Nova-api] Error when generating REST stubs from compute api wadl

Okay, I looked over the issue in detail. There are a number of things going on: 1) WADL2Java expects XSD 1.0 but we're using XSD 1.1. That's actually not that big of a deal, because you can convert between the two by running the WADL trough our normalizer. See https://github.com/rackspace/wa

[Openstack] Extension Documentation

Hi All, I've started putting together a site to hold extension documentation. You can see it here: http://docs.rackspace.com/openstack-extensions/ The idea is to have a repository for all extensions, whether the extension is an OpenStack extension or a vendor specific extension. It makes sen

Re: [Openstack] OSAPI and Zones

Inline: On Nov 15, 2011, at 3:36 AM, Doude wrote: > Thanks a lot for your answers. > > But why do you want to move the Zone code into the extension part ? > It's a core part of OpenStack, why it doesn't stay in the core code ? If something is in core then it's guaranteed to be available always.

Re: [Openstack] describing APIs for OpenStack consumers

The core API WADL is here: https://github.com/openstack/compute-api/blob/master/openstack-compute-api-1.1/src/os-compute-1.1.wadl Keystone also has a number of WADLs here: https://github.com/openstack/keystone/tree/master/keystone/content -jOrGe W. On Nov 14, 2011, at 2:21 PM, Rupak Ganguly wr

Re: [Openstack] OSAPI and Zones

Last time I had a conversation about this, I believe the goal was to refractor and document Zone support as an extension to the core API. We're just not there yet. -jOrGe W. On Nov 14, 2011, at 9:49 AM, Doude wrote: > Hi all, > > I'm trying to understand the multi-zone architecture of OpenSt

Re: [Openstack] Nova-API Team Meeting Notes

Thoughts on v1.1 -> v2 rename. 1. As stated: URI changes /v1.1/ to /v2/ though we keep redirecting 1.1 requests to v2.0. 2. Mime type accepts version=2 as a parameter but still responds to version=1.1 so the following will remain valid mimeTypes: a) application/vnd.openstack.compute+x

Re: [Openstack] Push vs Polling (from Versioning Thread)

Huh? I didn't write that. George did. On Oct 28, 2011, at 11:35 AM, Caitlin Bestler wrote: > Jorge Williams wrote: > >> Push notifications don't make your core system any more complex. You push >> the change to a message queue and rely on another system to do the

Re: [Openstack] Push vs Polling (from Versioning Thread)

On Oct 28, 2011, at 10:33 AM, George Reese wrote: > You are describing an all-purpose system, not one that supports the narrow > needs of IaaS state notifications. > > There's no reason in this scenario to guarantee message delivery. Like I said, there are a lot of factors to consider. And

Re: [Openstack] Push vs Polling (from Versioning Thread)

On Oct 28, 2011, at 8:11 AM, George Reese wrote: Push notifications don't make your core system any more complex. You push the change to a message queue and rely on another system to do the work. The other system is scalable. It has no need to be stateless and can be run in an on-demand format

Re: [Openstack] +1, All services should have WADLs

oal isn't to make, parse, or manually read WADL's - it's to make this set of web pages. If WADL helps me get there expediently, I'm all over it. -joe On Oct 27, 2011, at 11:03 AM, Jorge Williams wrote: As I stated in previous emails, we are pulling data from the WADL t

Re: [Openstack] +1, All services should have WADLs

As I stated in previous emails, we are pulling data from the WADL to grab human-consumable REST API docs that live at docs.openstack.org today. We can certainly expand that capability to create a unified API documentation set rather than individual guides. A lot of

Re: [Openstack] API Versioning and Extensibility

On Oct 27, 2011, at 8:56 AM, George Reese wrote: On Oct 27, 2011, at 8:11 AM, Jorge Williams wrote: Response inline: On Oct 27, 2011, at 12:50 AM, Bryan Taylor wrote: On 10/26/2011 04:45 PM, Jorge Williams wrote: On Oct 26, 2011, at 1:19 PM, Bryan Taylor wrote: So no pdfs or excel

Re: [Openstack] API Versioning and Extensibility

Response inline: On Oct 27, 2011, at 12:50 AM, Bryan Taylor wrote: > On 10/26/2011 04:45 PM, Jorge Williams wrote: >> >> On Oct 26, 2011, at 1:19 PM, Bryan Taylor wrote: >> >>> So no pdfs or excel spreadsheets without conneg. >> >> But PDFs and exc

Re: [Openstack] API Versioning and Extensibility

On Oct 26, 2011, at 1:19 PM, Bryan Taylor wrote: So no pdfs or excel spreadsheets without conneg. But PDFs and excel spreadsheets are precisely why you want variants! "Here's my usage stats for 2009... http://usage.api.acme.com/v1.0/jorgew/2009/usage.pdf"; You mean to tell me that I can't sen

Re: [Openstack] +1, All services should have WADLs

++Totally agree with that approach. Looking forward to looking over the Images 2.0 API :-) -jOrGe W. On Oct 26, 2011, at 10:23 AM, Jay Pipes wrote: > On Wed, Oct 26, 2011 at 1:06 AM, Mellquist, Peter > wrote: >> The topic of when an API should be defined is also important. Do we define >> an

Re: [Openstack] +1, All services should have WADLs

I don't mind generating a WADL so long as we have a good expressive tool for doing so. I haven't found one yet. There was a project a while back for doing so called "Rest Described and Compile" that seemed to be heading in the right direction, but it hasn't been worked on in a while. http://to

Re: [Openstack] describing APIs for OpenStack consumers

The WADL should be complete for Nova. There are a couple of error fixes that I've completed but haven't pushed up yet. I'll try to get to those tomorrow and I'll look over Nachi's contributions as well. What's not done in Nova is documenting all of the extensions. I'm working on that and wil

Re: [Openstack] describing APIs for OpenStack consumers

00 lines script. > > I used lxml.objectify > http://lxml.de/objectify.html > > You can read wadl as python object. > It is very easy to generate something from the WADL if you know WADL > structures. > > xsd_root = objectify.parse("PATH2WADL").getroot() > x

Re: [Openstack] describing APIs for OpenStack consumers

Totally agree. The goal is to create narrative documents that devs can read etc. The WADL is just there to fill in the nitty gritty details in a consistent way. -jOrGe W. On Oct 25, 2011, at 5:34 PM, Caitlin Bestler wrote: WADL sounds like a wonderful validation tool. But shouldn’t our prim

Re: [Openstack] describing APIs for OpenStack consumers

: Which dev docs and how? I haven't spotted those scripts or systems... -joe On Oct 25, 2011, at 2:58 PM, Jorge Williams wrote: Some of that dev guide documentation is generated from a WADL :-) The purpose of a WADL is that it is machine readable so it opens up a lot of possibili

Re: [Openstack] describing APIs for OpenStack consumers

Some of that dev guide documentation is generated from a WADL :-) The purpose of a WADL is that it is machine readable so it opens up a lot of possibilities, for creating docs, testing, validation, etc. -jOrGe W. On Oct 25, 2011, at 4:14 PM, Daryl Walleck wrote: Hi everyone, This is just my

Re: [Openstack] describing APIs for OpenStack consumers

Hi Nati, I've actually fixed some of the issues you're describing but haven't had a chance to check these in. Let's talk about the issues you're seeing off line and combine our efforts. -jOrGe W. On Oct 25, 2011, at 3:52 PM, Nati Ueno wrote: > Hi Joe, Anne > > I'm working on WADL of Openst

Re: [Openstack] describing APIs for OpenStack consumers

We've done quite a bit of work to get high quality documentation from a WADL, in fact we are using some of this today. We've taken most of the hard work re: parsing the WADL, at least for the purpose of generating docs from it and of writing code that can read it (though that later part can us

Re: [Openstack] OSAPI equivalent of euca-get-console-output ?

Moving forward this should be exposed in something like /servers/{id}/rax/console to avoid conflicts. -jOrGe W. On Oct 21, 2011, at 1:57 PM, Glen Campbell wrote: At Rackspace, we have developed an extension that returns the URL of a console via /servers/{id}/console. The issue for putting thi

Re: [Openstack] Some updates to REST API specs

We had extend discussions about the HTTP error code that we retuned for rate limiting while discussing the compute API. The issue is that we allow users to discover and query their rate limits. So an over-limit response should be in the 400 range because we see it as a client error. None of t

Re: [Openstack] Guidelines for OpenStack APIs

++ Like the idea..yes I think we should aim to include all OpenStack APIs -- whatever that means :-) -jOrGe W. On Oct 11, 2011, at 9:52 AM, Jay Pipes wrote: > On Tue, Oct 11, 2011 at 10:08 AM, Mark McLoughlin wrote: >> On Tue, 2011-10-11 at 16:11 +1100, Mark Nottingham wrote: >>> +1 (sorry for

[Openstack] Repose now on GitHub

Thanks to all who attended our chat Repose today. Just wanted to send a quick message to let you know that the code is available today on GitHub! https://github.com/rackspace/repose -jOrGe W. This email may include confidential information. If you received it in error, please delete it. ___

Re: [Openstack] Guidelines for OpenStack APIs

Starting from a set of goals makes sense to me as well. I had put together a sample set of goals for the PPB proposal a week or so ago and some sample guidelines. You can find them here. Standards for standards sake don't make sense to me either. http://wiki.openstack.org/Governance/Proposed/API

Re: [Openstack] Guidelines for OpenStack APIs

On 9/19/11 1:03 AM, "Mark McLoughlin" wrote: >The spec is actually quite clear on the different between PUT and POST: > > "The fundamental difference between the POST and PUT requests is > reflected in the different meaning of the Request-URI. The URI in a > POST request identifies the res

Re: [Openstack] API Spec

On Aug 24, 2011, at 12:02 PM, Soren Hansen wrote: 2011/8/24 Jorge Williams mailto:jorge.willi...@rackspace.com>>: Let me start by saying that I have no idea why we're having this discussion again. We talked about it at the design summit and we agreed we'd move forward in pretty

Re: [Openstack] API Spec

at I really care where it lives, I just don't remember talking about it. > > 2011/8/23 Jorge Williams : >> I don't have a problem moving the spec out of docs manuals and into another >> project even the nova repo. But, I do have a number of issues with the >&g

  1   2   3   >