Skip to end of metadata
Go to start of metadata

Summary:Gathering of Fridays meeting into confluence, and separation of Schema from Type

jgarnett hello?
jgarnett Hi Gabriel
groldan Hi Jody
jgarnett Check it out - I finally got Complex type support!
groldan ? where?
jgarnett http://docs.codehaus.org/display/GEOTOOLS/Review+of+FeatureType+Models#ReviewofFeatureTypeModels-discussion
jgarnett I went through each aspect of the design we need to consider
jgarnett and we finally got something good for complex types
jgarnett the inspiration was Just and James
jgarnett Justin pointed out the flaw
jgarnett and James mentioned always forgetting that there was a difference between the Schema and the Objects.
groldan can you look if it makes sense?: http://docs.codehaus.org/display/GEOTOOLS/FeatureType+Survey#FeatureTypeSurvey-Enhancementsproposal
jgarnett So I made it explicity - anything ending with Type actual is an object in the resulting model
jgarnett (or a node in the resultig GML)
jgarnett and anything ending with Schema is just used for validation.
jgarnett I am very happy with the split.
jgarnett So yeah - that does not make sense.
jgarnett I cannot by looking at a FeatureType/AttributeType system figure out which entries are "nodes" in the XML document.
groldan (looking at the doc)
groldan what call you a "node"?
groldan a leaf?
jgarnett Or I suppose I could based on pre knowledge that UnionAttributeType is not really a object, but instead an element of validation
jgarnett Node is something that is addressable by XPath.
jgarnett element or lead.
jgarnett See that ComplexAttributeType has an actual Node/Object associated with it?
jgarnett ChoiceAttributeType does not.
jgarnett For one ComplexAttribute Type you may have a sequence of three elements, a choice, and then a feature
jgarnett If you have an eample XML document I will chunk it into a breakdown of nodes for you.
jgarnett That is what I am trying to do here - http://docs.codehaus.org/display/GEOTOOLS/Review+of+FeatureType+Models#ReviewofFeatureTypeModels-requirements
jgarnett but your example did not have a surrounding FeatureCollection.
jgarnett Justin is with me and told me not to type so much, and give you a chance to read.
groldan yeah, trying to figure out what you writen on the doc.. sorry
jgarnett Ask me questions as you have them, I hope the format is understandable.
jgarnett If you have an XML document I can work on the node breakdown while you read?
jgarnett (note to self: failing not to type so much)
groldan let me see.
-->| jdeolive (n=chatzill@mail.refractions.net) has joined #geotools
jgarnett I like you AtomicAttributeType ...
jgarnett Here is the link to the pictures justin
jgarnett http://docs.codehaus.org/display/GEOTOOLS/FeatureType+Survey#FeatureTypeSurvey-Enhancementsproposal
groldan I was going to explain them a bit, ask me if you have any question
jgarnett Seems like a good idea.
jgarnett I did not go that far in my breakdown of modeling power (it was not needed, your AtomicAttributeType is a superset of my SimpleAttribtueType). I can just change the name.
groldan I'm having trouble trying to follow your Schema/Type discussion (though its my problem: lots of things on the head and its late)
jgarnett I did not know you could include documents with pictures (it did not used to work)
jgarnett It will be easier to talk you through it when we have a common example writen up.
jgarnett I will write up the small snipet I have already then ...
jgarnett The difference is between validation and containment
jgarnett validation = schema, containment = attributeType
groldan I'm sending you some RobA xml examples
jgarnett XPath is only worried about containment.
jgarnett Email?
groldan yes
-->| mleslie_ (n=mleslie@mail.refractions.net) has joined #geotools
jgarnett I am editing your page so the headings are links ... helps when revising.
groldan yeah, thanks. I didn't knew that
jgarnett Oh it is just some convention I follow
jgarnett too many times I have had to edit a page to figure out what page it included, to go edit that page ... annoying.
groldan I was going info/page
groldan though this is more practical
jgarnett You know about the macro?
jgarnett It will make TOC for you
groldan nope
jgarnett and if you include

Unknown macro: {exceprts}

short description in the page
jgarnett it will show up as a note next to the entry in the TOC
groldan uh, I would been saved some time
groldan
jgarnett See http://docs.codehaus.org/display/GEOTOOLS/Downloads
jgarnett each download page is a child. To make a new release we just make a new child page, everything else is automagic.
groldan ja, thats cool
groldan ok, can I try to explain a bit my point?
jgarnett Sure
jgarnett just got your email
groldan (well, let me finish reading your doc first)
CIA-10 jeichar * r15495 udig/plugins/ (6 files in 5 dirs): ops now have enablesfor
jgarnett okay .. lets get back in like 5-10 min when I have your email done up as nodes...
groldan ok
groldan it seems like you're considering "navigatable nodes" those attributes with an atomic value?
groldan if so, I should note that's not consistent with the XPath definition of node:
groldan http://www.w3.org/TR/xpath#data-model
groldan A node value (an element node value in the case of a complex attribute) is compund of the values of its children
groldan so a complex attribute (an element with children) is a navigatable node by itself
jgarnett Sorry just saving your worked example
jgarnett have the node breakdown
jgarnett and am starting to consutruct xpath examples.
jgarnett Yes.
groldan nice
jgarnett http://docs.codehaus.org/display/GEOTOOLS/Review+of+FeatureType+Models#ReviewofFeatureTypeModels-requirements
jgarnett Does the node breakdown make sense?
jgarnett Note - I am leaning XPath as I write this. It is not like I am an expert here.
groldan (page loading....)
jgarnett And yes, complex attribute is navigatable by XPath - if it was not we would not have to reveal its structure as part of our type information.
jgarnett It would be an AtomicAttributeType of some sort.
jgarnett You can really see how they would do reprojection, grab all the coordinates everywhere and hit them with an XSLT transformation.
jgarnett Got the page?
groldan yes
groldan still dont understand the separation between AttType and Schema
jgarnett Okay.
jgarnett Containment - what object is contained in another.
jgarnett We need to describe what is actually there.
jgarnett That is the ComplexAttributeType and AtomicAttributeType
jgarnett with me so far?
groldan yeah
jgarnett Now we also have the concept of Valid (totally different from containment)
jgarnett Choice, Multiplicity and Sequence
jgarnett descirbe that.
jgarnett So for a ComplexAttribtueType we need both. What attribtues are we allowed, and what constraints exist
jgarnett When we mix the two people expect to see one object, or node, per attribute type.
jgarnett James did it in the meeting.
jgarnett Does the choice/multiplicity/sequence == validity check make sense?
groldan it makes sense, just that all that defines the type imho, as well as a facet does for a simple type
groldan the point:
jgarnett At the very least separating them has really made explicit the difference between validation converns and xpath concerns.
jgarnett One of the things we cannot do with the current system is load and fix invalid content.
jgarnett With this new one we would be able to.
jgarnett So the question is, is this separation worthwhile?
jgarnett You do understand the separation now?
jgarnett My problem with your picture is that when I trying to figure out what the data looks like based on the schema
groldan not completelly, to be honest
groldan ah, ok, lets review it:
jgarnett I cannot tell what is going on with containment, when ChoiceAttribtueType extends ComplexAttributeType
jgarnett So there are two questions being asked of out "Type" system.
jgarnett What is valid.
jgarnett And what does the data get constructued like.
jgarnett for: SEQUENCE( A CHOICE( B, C ) )
jgarnett we can have data that looks like:
jgarnett - A B
jgarnett or A C
jgarnett but if I look at the type system
jgarnett I expecct ( A, (B,) )
jgarnett and ( A (C, ) )
groldan that's the point: we cannot have DATA separated from the type, we need typed values
groldan and that is what is supposed to be: what your'e expecting
groldan let me face it:
jgarnett I know that - A and B and C could be ComplextTypes
jgarnett The typing of values is ifferent from constrains on their order and appearance.
jgarnett multiplicity is a separate concern form complex type support. Choice is a separte concern form complex type support.
jgarnett You were right when you said that Choice/Sequenece/All are closer to facets then anything else.
jgarnett (Not sure If I am helping Gabriel, I wish justin was around as he has more GML experience then me)
groldan youre helping, just trying to figure out the whole problem, since I'm pretty sure my proposed model covers the needs
jgarnett It covers the needs for validation, but it does not cover the need for modeling.
groldan so you see choice and friends at the same level of a facet?
jgarnett Yes, the only thing a choice can do is make a validation error
groldan they're about modeling a type
jgarnett It cannot make a new object!
jgarnett They are about modeling a valid content for the containing complex type.
groldan I see your point now
jgarnett Wish I had a better example to explain with
groldan I would like to agree on one thing:
jgarnett sure.
groldan we can face it in a way to have choice and friends at the same level than a facet for a single type, right? so we will have just a singleComplexAttributeType in the hierarchy
jgarnett face = phrase? As in wording ?
groldan yes, sorry
jgarnett Just checking, I can't spell myself.
jgarnett Yes we can do that, you can see on my page I made FeatureType extend ComplexType
groldan that's making a lot of sense for me now
jgarnett (and FeatureCollectionType extends FeatureType)
jgarnett So I had do have more then one ComplexType in the system. What is bugging me
jgarnett is FeatureCollectionType.
groldan so the one thing I want to agree on:
jgarnett (it comes down to featureMembers and featureMember being "magic")
groldan look at the FeatureType diagram
jgarnett yes.
groldan so a feature content is a sequence of tree like structures, of typed values
groldan the AttributeValue thing is a recursive association: a tree
jgarnett Yes that is what a Feature is.
groldan holding a type and a value
groldan the semantics for what exactly that value is, are well defined in terms of AttributeType definition and multiplicity
jgarnett I think I called it "Attribute" in my outline. But Yes we need an object to hold AttribtueType and Value
jgarnett only in terms of definition
jgarnett multiplicity controls how many times the AttributeValue can appear in the sequence.
groldan by the way, AttributeType now has a QName (I'll steal GenericName from GeoAPI since it already does the job)
jgarnett QName exists as a normal Java class these days
groldan (what GeoAPI is going to use so?)
jgarnett Not sure we will have to ask.
jgarnett Gabriel we are both keeping documents going here on similar content. I would like to keep the design decisions document if possible.
groldan I'm ok with that, just I need them included since my doc is a project deliverable
jgarnett Okay.
jgarnett Can you make a picture out of what I have now?
jgarnett There is a lot fewer methods since I had the luxury of breaking backwards compatability.
jgarnett I had a question about the sub types of AtomicAttribtibuteType
groldan so you're happy with my design provided that choice/seq/all are validation beasts?
groldan tell me
jgarnett (sorry answering a question from a user)
groldan np
jgarnett Yes - we are on the same track. I would like to remove a lot of the "historical" methods like getAttributeCount()
groldan sure
jgarnett NumericAttributeType - that comes right from XMLSchema right? You don't need a specific one for GML2 and GML3 ?
groldan all atomics are from XML Schema, yes
jgarnett Cool - I mentioned it before. But we should try and agree with the same mapping for atomics that JAXP uses.
groldan the different atomic types are groupings of the same XML Schema primitive type, thus allowing the same set of facets
jgarnett I understand, we have been working on a XML parser.
groldan does JAXP covers all of them or is just limited to the most used ones?
jgarnett Union seems complicated to me, may need special attention.
jgarnett Unsure, subject for reaearch. I just know people will complain if we make different mappings then what they are used to .
groldan yes, may complicate things if grouping types of the same family
jgarnett (darn sun approved APIs)
jgarnett So we got one area where I am unhappy still
jgarnett featureCollection children
groldan anyway, I think they shuold be pretty obvious
jgarnett as described by FeatureCollectionType
groldan yes, lets swithc to FC
groldan (gimme 1', need to go WC)
jgarnett Perhaps we should draw up what we have agreed on so far?
groldan (ready)
groldan first I need to confirm something:
jgarnett I am not sure I am, I can tell you where I am uncomfortable though.
jgarnett Sure ... confirm away.
groldan currently FC is not respecting the AbstractFeatureCollectionType right? as it is not respecting the association type pattern, as far as I seen
jgarnett FC does have a FeatureType associated with it - and that FeatureType has AbstractFeatureCollection as a super type.
jgarnett If it does not it is a bug.
jgarnett (or one of those gaps between the "model" and the "implementations")
groldan yeah, I guess so, since FC is being asked by members directly through the member type name
jgarnett Well right now GT has FC.getType() and FC.getSchema()
jgarnett getType is the FeatureType of the collection
jgarnett getShema is the FeatureType of the children
groldan I guess myFC.getAttribute("featureMember"):FeatureList is your perfect fit for random access?
groldan I made a few notes on the subject (looking up the link)
jgarnett that is the difficulty alright
groldan http://docs.codehaus.org/display/GEOTOOLS/FeatureType+Survey#FeatureTypeSurvey-FeatureCollection
jgarnett is featureMember "magic" and avaiable as myFC.features() ?
groldan yes, but that's a convenient implementation detail
jgarnett but if we did not have it
groldan for dealing with a FC through its Feature interface you need to respect the FCType
jgarnett "featureMembers" would show up as a normal attribtue just like everything else.
jgarnett And we would not need a special FeatureCollectionType
groldan I thought your point was being able of dealing with FC through its Feature interface
jgarnett As I said Gabriel - this is where I cam kind of stuck
groldan you can break GML analogy and avoid featureMember(s) attributes
jgarnett I dont't know if featureMembers is an Attribute or not?
groldan it is
jgarnett It is in GML and in XPath
groldan yes, both are the actual attributes of a FC type
groldan both follow the association type pattern, as mandated by GML
groldan they're of different type though, featureMembers is an ARRAY of features, featureMember is a single feature association with multiplicity 0..N
jgarnett (sorry customer again)
groldan wether you ask FC.getAttribute("featureMember") or FC.getAttribute("featureMembers"), you'll get a List of features
jgarnett It would be very nice for users of FeatureCollection to be able to ignore that difference wouldn't it?
jgarnett I wonder what the difference looks like from the XPath node point of view?
groldan through the legacy FC.features()
jgarnett I asked justin for help
jgarnett Justin we are fretting (well I am, gabriel is happy) about the handling of featureMember(s) and if that should be done directly
jgarnett as an "fatureMember" FeatureType (used as an AttribtueType) with muliplicity 0..N
jgarnett or as FeatureCollectionType.getChildFeatureType()
groldan by the other way, knowing which's the members type is actually extending by restriction AbstractFeatureCollectionType
groldan though completely valid, having this capability would worth better allowing more than one member type?
groldan getAllowedMemberTypes():Set<FeatureType>
jgarnett Gabriel we are not sure what to say.
groldan I mean:
jgarnett We both simply dont know enough.
groldan (nor me...) we do know the members type for the sole reason that most the time a FC is the result of a query to a FeatureType
groldan but that is not in the power of the general FeatureCollection
groldan though, it IS expected that you extend it when designing your GML application schema, for example, to restrict its member types, or even adding properties to the base collection type, right?
groldan so, if we're implicitly allowing this first kind of extension, for making easier the life of the developer, why restrict it to a single FeatureType member?
jgarnett I am not sure
jgarnett what I am sure is we need to communicate that restriction (if present) as part of the FeatureType/AttribtueType system
jgarnett (other wise people may try to consturct a FeatureCollection with invalid members)
jgarnett Q: You like AtomicAttribtueType better then SimpleAttribtueType ?
groldan Atomic reflects the semantics defined in XMLSchema
jgarnett Okay
jgarnett And in your enum AtomicType.Integer would have NumericAttribtueType ...
jgarnett just writing it up for design decisions ...
groldan (sorry was at the phone)
groldan (phone again)
jgarnett jgarnett Oh wait Atomic is for XMLSchema atomic stuff right ?
jgarnett How did you want to handle people putting raw objects in ?
jgarnett ie things that don't bind to XS:SimpleType
jgarnett But are not navigatable by Xpath ...
jgarnett Sorry lavila - wrong window
jgarnett (I am sure that was very confusing)
groldan NumericAttributeType.getType() shall be one of the types in the enum derived from decimal
jgarnett I just tried talking to my customer about this stuff - sigh.
jgarnett What I was trying to say is does Atomic imply a close set defined by XMLSchema
jgarnett or is it open ?
groldan a close set, all xml types are derived from one of those atomic types, or from a complex type
groldan does that answer your question?
jgarnett No
jgarnett what about my application
jgarnett where I have a elmeent defined from xs:string
jgarnett that I parse into a CoordinateReferenceSystem
jgarnett featureCollection srs attribtue for example ...
jgarnett That is atomic
jgarnett but its Java class is not one provided by XMLSchema
jgarnett Is it Atomic or mearly simple?
jgarnett Basically do I need SimpleAttribtueType
jgarnett AtomicAttribtueType extends SimpleAttributeType
jgarnett or can/should there be only one?
groldan regardless of the need of creating another simple types than the ones defined in xml schema, the hierarchy is modeled following xml schema typing system
groldan since simple types are not only atomic ones
groldan list and union are alse
groldan also
groldan as well as our legacy Geometry
jgarnett Here is what happened
groldan GeometryType is not atomic because you can't encode a list of geometries as a space separated list on a xml attribute
groldan (well, may be as WKT
jgarnett interesting is that the metric for "list" then ?
groldan yes
groldan but you can define a type as a union of an Integer or a Polygon, so union references simple types, not just atomic ones
groldan does it makes sense?
jgarnett It does but I have a hard time turning it into java code.
jgarnett Right now I am making up a design decisions section with Java interfaces for what you describe
jgarnett (but it is not yet consistent)
jgarnett I will save the page shortly and let you know, I hope you are making a diagram of what we agreed on so far?
jgarnett But perhaps you are working on something else ...
groldan didn't was making the diagram, but just because i forgot to do it... doing it now
jgarnett I think we will end up leaving FeatueCollection & FeatureCollectionType the way it is, it just makes me unconfortable
groldan Jody: what do you need from FC in the very short term?
groldan I know you want Feature API access to FC instances, right?
groldan but you're thinking if it is worth respecting the featureMember property stuff?
jgarnett Just a second almost ready to save ...
jgarnett saving
jgarnett We need to communitcate the featerMember restrictions out to end users as part of the FeatureType assocated with the FeatureCollection.
jgarnett Right now we are doing that be having a explicit FeatureCollectionType.getChildFeatrureType()
jgarnett That will and does work
jgarnett I am just conflicted because I don't know if that prevents featureMember from appearing as a normal attribute (of type Feature) with multiplicity 0..1
jgarnett We got two ways to do it, I am not even sure if they are in conflict.
jgarnett Okay I got a sample outline of AtomicAttribtueType for you
jgarnett I have it extending AttribtueType - but it does not add any additional methods.
jgarnett there is also the class AtomicType that has static final constants for the well-known XMLSchema type mappings.
groldan I see
jgarnett Opps messed up forgot to refer to the boolean attribtues
jgarnett and wrote them all up as classes not interfaces ...
jgarnett editing again
jgarnett Question
jgarnett can we even have AtomicTypes?
groldan ?
jgarnett Don't we always have a real Boolean element with its own multiplicity etc ...
jgarnett and its own name?
jgarnett I am pretty sure AtomicType and friends should be recast as a Factory for making your own ...
jgarnett I notice because AttribtueType has isWritable()
jgarnett It does not make sense to have isWritable on an StringAtomicType
groldan isWritable is for stating if an attribute is not "read only"?
jgarnett Does the problem make sense?
groldan not sure
jgarnett Okay we have a FeatureType that has name
jgarnett name is an xs:String
jgarnett we don't use xs:String directly
jgarnett we use an extention of it called "name" with multiplicity 0..1 and writable=true ?
jgarnett Question is how often (if ever) do people use naked AtomicAttributeTypes ?
jgarnett naked = non extended ?
groldan <element name="name" type="xs:string"/> ?
groldan too often
jgarnett I still think we messed up
jgarnett we are mixing model with implementation
jgarnett Basically I cannot do this:
jgarnett static final NumericAttribtue Byte = new AtomicAttribtueType("byte", java.lang.Byte.class ) implements NumericAttribtue;
jgarnett I will break out named inner classes.
jgarnett But still this strikes me as kind of non resuable ...
groldan hey, AtomicType are not AttributeTypes
jgarnett Okay so this was lost on me from your diagram ..
jgarnett what are they ?
jgarnett interface AtomicAttribtue extends Attribtue {
AtomicAttributeType getAttributeType();
}
groldan they're an enum of the atomic primitives defines in xml schema from where to infer the predefines value space of a primitive
jgarnett So what do they do?
jgarnett Are they attribute types?
jgarnett AtomicType is a marker
groldan no, they are value types (like the old AttributeType.getClass() but with predefined value ranges)
jgarnett getType returns one of those?
jgarnett Class getType()
jgarnett isn't that a conflict?
jgarnett oH it is not
jgarnett oh wait it is.
groldan why?
jgarnett Class AttribtueType.getType()
jgarnett vs
jgarnett Class AtomicAttributeType.getType()
groldan AttributeType.getType is gone, or you're going to always return Object.class
jgarnett you want to say that the second one is limited to one of the AtomicTypes with a known mapping.
jgarnett No
jgarnett What about Feature ... Feature.class
jgarnett Geometry ... Geometry.class
jgarnett LineString ... LineString.class ?
groldan mmm... I messed it up
jgarnett Saving the page again with a "Hack" section for the Atomic
jgarnett You goal is to ensure that XMLSchema atomic types are representable ?
jgarnett And that the mapping is captured explicityly Interger to BigInteger, int to Integer correct?
jgarnett (page saved)
jgarnett Opp! I forgot isNillable!
groldan thats right
jgarnett saving again
jgarnett you found the hack section, afraid I am probably done for the day (need to go onto other work)
jgarnett It is probably late for you as well ?
groldan yes, its becoming a bit late, thanks for your support
CIA-10 jeichar * r15496 udig/plugins/net.refractions.udig.catalog.wfs/src/net/refractions/udig/catalog/internal/wfs/WFSGeoResourceImpl.java: fixed potential bug for WFS
jgarnett Hey we made it a long way today
jgarnett We are down to two issues:
groldan Qname is Java 5
<--| Jesse_Eichar has left #geotools
jgarnett - jody does not like FeatureCollectionType (not much of an issue)
jgarnett - Gabriel wants mapping of AttomicTypes to be ecplicit
jgarnett (excplit rather)
jgarnett We can try again when you have an updated picture.
jgarnett Not sure how to indicate the mapping of atomic types
groldan note that having an explicit mapping
jgarnett (that is what you want to acomplish correct?) Or do you just want to ensure that such a mapping is possible?
groldan does not only makes things nicer, but allows to model app schemas that reuse all the meanings of its predefined restrictions
groldan why Not sure how to indicate the mapping of atomic types?
jgarnett Have a look on the page?
jgarnett You don't have a "superType" defined for attribtueTypes
jgarnett (which is what you are kind of asking for)
jgarnett so there is no way to reuse your predefined restrictions ...
jgarnett Every AttributeType is created afresh, no refernces to any other AttributeType anywhere ...
groldan new NumericAttributeType(AtomicType.Double)
jgarnett We reuse on FeatureTypes, not Complex types or AtomicTypes.
jgarnett I dont understand gabriel - where is that ?
jgarnett That is a constructor? We can't do constructors in an interfaces only spec ...
CIA-10 jeichar 1.0.x * r15497 udig/ (17 files in 11 dirs): fixed bug where WFS explodes when no geometry is available
groldan its implementation dependent, we shuold add AtomicType.getPredefinedRestrictions():Filter
groldan yeah, I mean NumericAttributeTypeImpl(...
jgarnett Okay - NumericAttribtueTypeImpl - has no bering on the modeling capability of our system.
groldan the interface says AtomicAttributeType hasA AtomicType, from which it obtains the set of predefined restrictions
jgarnett Okay .. is client code expected navigate getAtomicType() and look at the restrictions?
jgarnett Or do the restrictions get folded into the AttributeType.getFacets() ?
jgarnett If the former AtomicTypes are "special"
jgarnett and we should consider AttirbuteType AttirbuteType.getSuper()
groldan AtomicType was publicly visible because I (wrongly) moved AttributeType.getType():Class there
jgarnett so users have the same power for their own application schemas.
jgarnett okay ... so AtomicType is not part of the interfaces, only the implementation ?
groldan you may still need them to encode a GML doc (integer vs int?)
jgarnett Perhaps, and probably.
jgarnett jdeolive ? We are into parsing / writing issues now please advise?
jgarnett Justin is not here, he has parsing / writing experience.
jgarnett If you need that then you should consider setting up attributeType.getSuper()
jgarnett It would eliminate the need for FeatureType.getSuper() ...
jgarnett Then you can set up an interface XMLSchema with static final constants for the AtomicType ...
jgarnett And people can refer to them as needed ...
jgarnett Still this is a new tradeoff to consider (and not one I considered before).
groldan mmm.... it may be
jgarnett Well I did not consider it before and it did not come up on firday.
groldan ok, cool.
groldan good bye Jody, have a nice day
jgarnett Are you happy with where things are?
groldan I am happy, cause changind the chose/seq/all thing I have all I need to do progress with the project
groldan since this phase is taking more than expected
groldan so yes, its great having this level of acceptance
groldan unfortunatelly you still have your featurecollection concerns
jgarnett Well the real level acceptence is when we merge in the changes and break every project that uses geotools and geoapi
jgarnett It is just unease, what we have is "complete" in a modeling sense.
groldan but that was a friday's design desition
jgarnett I just wonder if we are duplicating information.
jgarnett True but as you can see, design decisions somtimes fail when we meet cold hard Java interfaces.

  • No labels