[openroad-developer] Empire XML Support - Two review
meetingtimesscheduled on May 20th 2008
Sean Thrower
Sean.Thrower at ingres.com
Fri May 23 04:25:49 PDT 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
* Customized definition stores, like queryobjects
* 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/df5619ec/attachment-0001.html
More information about the openroad-developer
mailing list