[openroad-developer] Empire XML Support - Two
reviewmeetingtimesscheduled on May 20th 2008
Durwin Wright
Durwin.Wright at ingres.com
Fri May 23 12:11:13 PDT 2008
Hello Bodo,
I agree with your proposal for using XML attributes to encode Userclass
attributes rather than XML elements. There are no restrictions on XML
attributes. There is a further advantage that XML entity names could be
used to encode characters that may not exist in the specific character
set if it is not UTF8.
Durwin Wright | Sr. Architect | Durwin.Wright at ingres.com
<blocked::mailto:Durwin.Wright at ingres.com> | Ingres | 500 Arguello
Street | Suite 200 | Redwood City | CA | 94063 | USA
<blocked::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-5523 |
fax: +1 650-587-5550
________________________________
From: openroad-developer-bounces at lists.ingres.com
[mailto:openroad-developer-bounces at lists.ingres.com] On Behalf Of Bodo
Bergmann
Sent: Friday, May 23, 2008 9:35 AM
To: Roger L. Whitcomb; Sean Thrower
Cc: openroad-developer at lists.ingres.com; Joseph C. Kronk
Subject: RE: [openroad-developer] Empire XML Support - Two
reviewmeetingtimesscheduled on May 20th 2008
I think Sean is after something else:
Given a UserClass "My$Customer" with attributes like:
- "cust#"
- "email@"
he wants for an instance with values cust# = 123 and email@ = 'x at y.z'
to create an XML like:
<My$Customer>
<cust#>123</cust#>
<email@>x at y.z</email@>
</My$Customer>
This is what the current SessionObject.Gen_Xml() method would create,
but it's obviously invalid as $, @ and # (though valid in values) are
not valid in XML tag names.
So, Sean wants something that makes it valid,
e.g. by mapping "$" to ":1", "@" to ":2", "#" to ":3", which would
result in:
<My:1Customer>
<cust:3>123</cust:3>
<email:2>x at y.z</email:2>
</My:1Customer>
Though this is basically possible, I don't see this as a practical
solution - it makes reading hard
and requires additional steps when parsing it back.
I rather opt for using attribute values rather than tag names for such
UserClass-XML mapping,, e.g.:
<obj classname = 'My$Customer'>
<attr name='cust#'>123</attr>
<attr name='email@'>x at y.z</attr>
</obj>
Bodo.
_____________________________________________
From: Roger L. Whitcomb
Sent: Friday, May 23, 2008 5:52 PM
To: Bodo Bergmann; Sean Thrower
Cc: Joseph C. Kronk; 'openroad-developer at lists.ingres.com'
Subject: RE: [openroad-developer] Empire XML Support - Two review
meetingtimesscheduled on May 20th 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
<mailto: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
<mailto: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/15b6543b/attachment-0001.html
More information about the openroad-developer
mailing list