[openroad-developer] Empire XML Support - Two review
meetingtimesscheduled on May 20th 2008
Roger L. Whitcomb
Roger.Whitcomb at ingres.com
Fri May 23 08:51:41 PDT 2008
Actually, I think we're making this a bigger deal than it needs to be. I came to realize this during the second call. Consider this really ugly UserClass definition (which I don't even know if it is legal in OR, but suppose for the sake of argument that it is):
UserClass abc
property: "It's a <widget>"
method: "<Work it>"
Now, we have to convert this to XML, which might look something like this:
<UserClassDefn classname="abc">
<property name="It's a <widget>"/>
<method name="<Work it>"/>
</UserClassDefn>
Now, notice that what we're talking about in the XMLAttribute spec is creating an attribute (for instance), giving it a name and a value. So, when we create the attributes for the <property> element, it has just one, whose name is "name" and whose value is "It's a <widget>". So, what we are talking about in this discussion is the case where the name would be something like "<ugly name>" which would (if it were possible) look like this in the XML:
<property <ugly name>="<ugly value>" />
Well, obviously that doesn't work, but the name of attribute names is set by the schema/DTD designer, not by user input, and so are never going to have ugly values that we would potentially need to call IsValidName() for, because we (that is the 4GL developers) are making them up.
So, I think this is an entirely moot point, and we don't even need to talk about it.
Roger Whitcomb | Architect, Engineering | Roger.Whitcomb at ingres.com | Ingres | 500 Arguello Street | Suite 200 | Redwood City | CA | 94063 | USA <http://maps.google.com/maps?q=500+arguello+street,+94063&ll=37.487297,-122.233200&spn=0.004602,0.012771&t=k&hl=en> +1 650-587-5596 | fax: +1 650-587-5550
> _____________________________________________
> From: Bodo Bergmann
> Sent: Friday, May 23, 2008 5:14 AM
> To: Sean Thrower
> Cc: Joseph C. Kronk; Roger L. Whitcomb; 'openroad-developer at lists.ingres.com'
> Subject: RE: [openroad-developer] Empire XML Support - Two review meetingtimesscheduled on May 20th 2008
>
> Sean,
>
> I agree that we should support the 4GL developer with the best support we can,
> and "OpenROAD was designed from the start to meet the user more than halfway",
> but there is a difference between "ease of use" and an "automatic conversion from invalid to valid contents".
> The existing system classes didn't provide this either.
> Otherwise a WriteToFile(filename='C:\Documents and Settings\ingres\Local Settings\Temp\My Doc.txt')
> method invocation on Unix would work by automatically applying some "default" mapping for filenames and paths.
> We don't provide an EnsureValidFilename() method either :).
>
> With that said, I don't doubt, that the functionality you ask for might be useful/desired in some cases,
> but we should be careful in predefining a distinct implementation in generic system classes for a special purpose
> and thus limit the general usability as users are then bound to it - with no way to change it.
> The existing undocumented SessionObject methods for XML generating/parsing (Gen_xml, Xml_In)
> are a good example for a (useful) functionality which forces users to follow a distinct way -
> this resulted in many "Software Improvement Requests" (and bug reports) from users, as it is not flexible enough.
>
> Therefore, I think there are better ways for dealing with special features
> (e.g. for mapping from UserClass object/arrays into/from XML):
> - Additional System Class(es) - using the general purpose classes
> - 4GL (libraries, frameworks)
>
> And given the Open Source path we are going, it doesn't mean that Ingres Corp. has to provide all this stuff "out of the box".
> There could also be different implementations by different providers (as we have it in other development tools as well).
> The Community should be a big help - the best implementation will soon become the most adopted.>
>
> OpenROAD developers then have the ability to decide,
> if they want to use one of these offerings - or just develope their own.
>
> Regards,
> Bodo.
>
> Bodo Bergmann | Sr. Software Engineer | Bodo.Bergmann at ingres.com | Ingres Germany GmbH | Ohmstr. 12 | 63225 Langen | GERMANY | +49 6103 9881 0
>
> _____________________________________________
> From: Sean Thrower
> Sent: Friday, May 23, 2008 1:26 PM
> To: Bodo Bergmann
> Cc: Joseph C. Kronk; Roger L. Whitcomb; 'openroad-developer at lists.ingres.com'
> Subject: RE: [openroad-developer] Empire XML Support - Two review meetingtimesscheduled on May 20th 2008
>
> Bodo,
>
> Thanks for your detailed response. IsValidName at least solves the most intractable problem.
>
> Obviously I didn> '> t suggest these items without having thought through all the questions you posed, and found good answers for them.
>
> I suspect that we are simply differing at the level of what a user-developer expects from a 21st century interface - in particular, what features/functions are provided by, and therefore guaranteed, by the product/language, as opposed to the remaining features that the user-developer will have to (develop and test and) guarantee: obviously the more sure-to-be-needed features that the user-developer gets out of the box, the more likely they are to use the product successfully and be able to defend it to their management.
>
> OpenROAD was designed from the start to meet the user more than halfway. Most of its OO-nonstandard features have proved enormously advantageous; others have not; each needs to be judged on its merits (ClientText is a relevant example here).
>
> I apologise for my rather casual phrasing of "developer creating an XML document ... from a type-value list of some kind". I was specfically thinking of tablefield columns and userclass attributes, for which (in case they include xml-incompatible names, as presumably they may) each user-developer will have to develop his own handlers.
>
> I am not of course commenting on the overall validity of your solution! It looks fine to me.
>
> Regards,
> Sean.
>
>
> _____________________________________________
> From: Bodo Bergmann
> Sent: Wednesday, May 21, 2008 9:08 AM
> To: Sean Thrower
> Cc: Joseph C. Kronk; Roger L. Whitcomb; 'openroad-developer at lists.ingres.com'
> Subject: RE: [openroad-developer] Empire XML Support - Two review meetingtimesscheduled on May 20th 2008
>
> Sean,
>
> here are my opinions on the issues:
>
> XMLAttribute.IsNonStandard
>
> This is in no way XML standard.
> I don't agree to add features for specific needs in the XML Support classes - they should be generic.
> If we have the ability of callbacks during parsing - as Roger suggested (and as already planned for the XML import facility) -
> you can just check the parsed attributes against your "standard set of xml attributes".
>
> XMLDocument.IsValidName(name=varchar(256))
>
> I agree to have the functionality, but I rather see it in the XMLAttribute and XMLElement classes
> (implementation in their superclass XMLNamedObject) than in XMLDocument
>
> XMLDocument.EnsureValidName(name=varchar(256))
>
> I do not agree to have this method - it is not generic.
> How would you ensure this - any varchar character which is invalid in XML names would have to be mapped to something valid.
> How do we define the mapping - just define "our own standard"???
> What does it mean when parsing back - has the mapped character to be converted back?
> How would you decide, if the element/attribute name containing a "mapped" character has to be converted back or
> if this is the actual correct name?
> We shouldn't provide support for something that's wrong, but rather tell people how to do it right.
> For your "developer creating an XML document ... from a type-value list of some kind" that just means,
> that rather than to use attribute and element names (s)he has to use according XMLAttribute values or characterdata of XMLElements.>
> Example (using your code):
> /* Don't do this if Type can contain invalid characters: nextElement.Name = list[counter].Type; */
> nextElement.Name = 'item'; // give it some generic name
> nextElement.AddAttribute(name='type', value=list[counter].Type);
>
> If you don't like it and still want to use "mapped" element/attribute names:
> Every 4GL developer is able to write a simple 4GL procedure "EnsureValidName",
> where the required/desired mapping can be accomplished and factored to the needs of the developer.
> This is much more flexible than providing this method,
> which is not generic and has potential for causing problems.
>
> Bodo.
>
> _____________________________________________
> From: Sean Thrower
> Sent: Tuesday, May 20, 2008 6:48 PM
> To: Bodo Bergmann
> Cc: Joseph C. Kronk; Roger L. Whitcomb; 'openroad-developer at lists.ingres.com'
> Subject: RE: [openroad-developer] Empire XML Support - Two review meetingtimesscheduled on May 20th 2008
>
> Bodo,
>
> Thanks for your helpful and careful responses to my comments.
>
> There were two specific issues that I raised at the meeting, that turned out to need a clearer exposition than I could provide at the time; so here below, as requested> ...>
>
> Regards,
> Sean.
>
> ...> ...> ...> ...> ...> ...> ...> ...> ...> ...> ...> ...> ...> ...> ...> ...> ...> ...> ...> ...> ...> ...> ...> ...> ...> ...> ...> ...> ...> ...> ...> ...> ...> ...> ...> ...> ...> ...> ...> ...> ...> ...> ...> ...> ...> ...> ...> ...> ...> ...> ...> ...> ...> ...> ...>
>
> XMLAttribute.IsNonstandard [TRUE, FALSE(default)]
>
> * All elements of a given kind have a standard set of xml attributes, the existence (and type) of which should be enforced.
> * However there will certainly be the need to specifically mark individual elements from time to time, in exactly the same way that there is the need to mark fields on the form (for which we provide ClientText) or attributes of a userclass (for which we only have remarks yukyuk). For XML elements, we only have additional (nonstandard) attributes
> * For any developer who has no use for it, the IsNonstandard property can be simply ignored entirely, just as ClientText is ignored by some developers
> * But when a developer needs an instance-specific attribute, by marking it as nonstandard (not to be schema-validated) they can still run the xmlattribute validation at any point in development or runtime to establish that the standard attributes are present, wholly present, and only present. In particular, misspellings will be correctly diagnosed
> * That> '> s probably enough to be going on with > ...> !
>
>
> rc = XMLDocument.IsValidName(name=varchar(256))
> validName = XMLDocument.EnsureValidName(name=varchar(256))
>
> * I had only considered the first of these, but I like the second.
> * For a developer creating an XML document based on attribute or element names from a type-value list of some kind, the code of their nightmares is:
> nextElement.Name = list[counter].Type;
> attempts = 0;
> WHILE nextElement.Name = > '> '> THEN
> attempts = attempts + 1;
> IF attempts > 10 THEN
> RETURN IveHadEnough( errmessage = > '> unable to satisfy unprintable OpenROAD checker> '> );
> ENDIF;
> list[counter].Type = OhThatWasntValidLetsTry( name= list[counter].Type);
> nextElement.Name = list[counter].Type;
> ENDWHILE; //how many trace messages this time?
> · The code of their dreams is:
> · nextElement.Name = XMLDocument.EnsureValidName( name= list[counter].Type);
> · > ...> Or if they are picky:
> nextElement.Name = XMLDocument.EnsureValidName( name= list[counter].Type);
> IF nextElement.Name != list[counter].Type THEN
> list[counter].aka = nextElement.Name;
> ENDIF; //look no trace message, graceful
> * Since IsValidName is going to have to exist anyway, why not expose it, preferably with some kind of mangler?
>
> _____________________________________________
> From: Bodo Bergmann
> Sent: Tuesday, May 20, 2008 2:48 PM
> To: Sean Thrower
> Cc: Joseph C. Kronk; Roger L. Whitcomb; 'openroad-developer at lists.ingres.com'
> Subject:> RE: [openroad-developer] Empire XML Support - Two review meetingtimesscheduled on May 20th 2008
>
>
> See comments below.
>
> _____________________________________________
> From: Sean Thrower
> Sent: Tuesday, May 20, 2008 1:48 PM
> To: Bodo Bergmann
> Cc: Joseph C. Kronk; Roger L. Whitcomb; openroad-developer at lists.ingres.com
> Subject: RE: [openroad-developer] Empire XML Support - Two review meetingtimesscheduled on May 20th 2008
>
> Bodo,
>
> Comments on the export format below.
>
> Regards,
> Sean.
>
>
> ...> I still don> '> t really get what > -> appsource is for: if it is to profile the application, it doesn> '> t tell you enough, since
> * the vnode::database out of context has no value
> [Bodo] See my other mail for comment.
> * the trickiest part of application inclusion is the build sequence, which could be pre-generated (I and no doubt others have code for this) and stored in the export, but can> '> t be generated from the export.
> [Bodo] Once the export file is in XML format, threre shouldn't be a problem to parse it and generate the build sequence from it.
>
> 3.3.1
> - Classname values lowercase:
> * This is inconsistent with our current systemclass standard (even if it is preferable:-))
> [Bodo] Why is it not consistent? If you create an attribute of a UserClass to some system class it will be automatically converted to lowercase.
> In addition it is a format which can be most easily be parsed (performance).
> This has nothing to do with the names of an actual UserClasses - these "classname" attributes are only for the purpose of export/import,
> e.g. for the component type.
> * Can I suggest that we store classname and displayname, to avoid later anguish? (I realize that this would at the present moment be a duplication, though hardly a serious one).
> [Bodo] I think there is a misunderstanding. If you talk of a UserClass, then this is a ClassSource, which has a name, which can be mixed case.
> This mixed case will be preserved, as the "name" will be written as attribute of the SOURCEOBJECT with classname "classsource", e.g.:
> <SOURCEOBJECT classname="classsource" name="MyClass"> ...
> · Specifically I don> '> t want to assume anything about future persistence of userclasses (which by OO convention have mixed-case naming), whether as
> · Customized data stores, eg. for Appserver
> 1 Customized definition stores, like queryobjects
> 2 System-class extensions
> - Treating stringobjects and bitmapobjects as special cases. Maybe I> '> ve misunderstood, but:
> * What happens to filehandle and dbhandle?
> [Bodo] We still have to decide if these attributes are relevant - they are definitly not required for restoring the value.
> They are just for the history of the object (where has it once created from), but that file or db stored something might not even exist when I import the export file.
> · Extension of these classes surely becomes impossible?
> · Suppose we were to introduce a persistent RW attribute at StringObject, BitmapObject, or even Object level, something that has been discussed in the past? Or implement variant as a TypeObject from which all datatype objects inherited?
> · No problem for export of other classes, but no way of doing so for these, if I have understood correctly?
> [Bodo] Why should it be impossible? If you extend the class then you extend the according methods that create the XML for it or recreate its attributes from XML.
> I don't see your point?
> - Base64 encoding:
> · I> '> m showing my ignorance here, but is this the best option in terms of text-based compression?
> · (What is making me twitchy here is that yesterday I was testing fp_clear on my empire installation (I nearly got it to work) and used the nearest bitmap to hand, a 1.3MB jpeg. Then I tried to save it > -> it had expanded to 50MB!)
> [Bodo] BASE64 is the standard way of doing this - we also use it when passing BitmapObjects to the OpenROAD Server.
> I know it's not ideal, but how about dynamically loading the bitmaps from files or db at runtime - then you don't blow up the FrameSource with it.
>
> 3.3.2
> - XML Schema:
> · I> '> m uneasy about the very loose coupling implied here between the schema and the hardcoded load process.
> · Is it possible to at least generate the schema from the internal definitions, so that there is some guarantee of consistency?
> [Bodo] That's not so easy as there is no 1:1 relationship between the internal implementation of attributes and the documented/human-readable output.
> But we should investigate this.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ingres.com/pipermail/openroad-developer/attachments/20080523/3c295438/attachment-0001.html
More information about the openroad-developer
mailing list