[openroad-developer] Empire XML Support - Two review
meetingtimesscheduled on May 20th 2008
Bodo Bergmann
Bodo.Bergmann at ingres.com
Wed May 21 01:08:01 PDT 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/20080521/c4f82fa2/attachment-0001.html
More information about the openroad-developer
mailing list