Subject: RE: What XML/DXL features would you like to see post-7.0?
Mac, if you are still listening, can you elaborate on what you meant by:- A ?ReadViewEntries param that would allow the entry data to be displayed in it’s hierarchy.
Subject: RE: What XML/DXL features would you like to see post-7.0?
Presently, ReadViewEntries is flat. The attributes of the viewentry nodes are what implies the relationship to their siblings.I feel that it would be much easier to work with the DXL if the structure of the document showed the relationships.
Something along the lines of…
URL - server/database/view?ReedViewEntries&hierarchy=true
Results -
<viewentry>
<entrydata>
<text></text>
</entrydata>
<viewentries>
<viewentry>
<entrydata>
<text></text>
</entrydata>
</viewentry>
<viewentry>
<entrydata>
<text></text>
</entrydata>
</viewentry>
</viewentries>
<viewentries>
<viewentry>
<entrydata>
<text></text>
</entrydata>
</viewentry>
</viewentries>
</viewentry>
<viewentry>
<entrydata>
<text></text>
</entrydata>
</viewentry>
Also, I think this would be helpful when used in conjunction with RestrictToCategory. The result from that would give us the viewentries and would allow XPath expressions to remain intact.
Subject: RE: What XML/DXL features would you like to see post-7.0?
But can’t you already build a hierarchy if you want today, based on the viewentry position attributes?
I’m not sure I immediately see any great benefits to this. How do others feel?
Thanks,
Dick
Subject: RE: What XML/DXL features would you like to see post-7.0?
I agree - not a big deal to accomplish with existing tools.
Subject: RE: What XML/DXL features would you like to see post-7.0?
True that attirbutes are available now for you to put together the hierarchy, but I think that this is a convience request more than missing functionality.Also, I still think that this would ease working with RestrictToCategory.
Subject: What XML/DXL features would you like to see post-7.0?
I’d like to see tight DXL integration into the designer client.
Imagine looking at a form in designer and at the click of a button be able to see that form in “DXL Mode.” In DXL mode you could preform search and replace functions to make sweeping changes. Then click the “traditional mode” button and see your changes. Add a “Split Mode” where you see the DXL and the traditional designer mode at the same time. Macromedia Dreamweaver already does this with HTML, there is a HTML mode, a rendered mode, and a split mode.
Imagine through integrated DXL being able to change attributes of dozens of fields with a simple search and replace. No more having to go to each one and click on properties and set checkboxes till your trigger finger hurts. Imagine all the saved mouse clicks. Imagine being able to do this without having to script an export, use a 3rd party tool, script an import, and then pray A DXL bug (shared actions anyone) doesnt kill you.
Otherwise fix the bugs with the current version. Its a very fradgile system right now where you have to do a lot of funky things to ensure a working export and moreso import. Anything from a shared action to a large bitmap in the About Database can crash the export and or import process. To be useful it needs to just work with as few cavets as is technically possible.
Subject: RE: What XML/DXL features would you like to see post-7.0?
Honestly a “live DXL” function in Designer would have to be FAR back on my needs list. What type of search and replace operations do you anticipate using? Things like hide-whens and other repeated formulas should be derived from computed-for-display fields – make your changes there. It would be nice, and save us some time on rare occasion, but primarily the features we’re all asking for here are things that can’t be done at all with DXL as it stands now.
Though I definitely give a thumbs-up for more robust and reliable importing. 
Subject: What XML/DXL features would you like to see post-7.0?
Dick, thanks for asking! Count me in for (1) and (7) for sure… with the URL class I would agree with Nathan’s caveat. As for any others, well (9) would be great, but I suspect more people would got for (10) – not too bothered about images myself.
Thanks!
–
Subject: What XML/DXL features would you like to see post-7.0?
I’d very much like to see #7, the “URL” class. I also think that #1, the ?SearchViewEntries, would be extremely powerful. I have lots of concerns about ?ReadDXL, and think that at the very, very least it should be disabled universally by default.
Subject: What XML/DXL features would you like to see post-7.0?
Hi Dick,for url commands my wishlist is here:
I vote for:
#1 ?SearchViewEntries
#2 ?ReadDXL – Here have the form properties determine what gets rendered – or some $DXLTransforms
#13 Complete representation
After that:
#11 Currently Whitespace is relevant inside a paragraph mixed with DXL (means:
<run …>…<run …>… is different from
<run …>…
<run …>…
Tables are a bit murky.
#7 URL Stream classes
#10 PNG/JPG please
#3
…
My 2c
stw
Subject: What XML/DXL features would you like to see post-7.0?
[]?SearchViewEntries: Like ?ReadViewEntries, but view contents are
determined by a full-text search. (Is this needed from Exporter APIs as well
(in addition to the Web Server))?[]
This is a MUST. Please see anything that Jack Ratcliff has done at
OpenNTF.org. The lack of this is a major impediment to the completion of his
projects.
[]?ReadDXL: URL command to get the DXL representation of a document or
design element. What are your security concerns? 1+ would be a parameter that
could apply an XSLT transform to the DXL and return the result – how important
is the 1+?[]
VERY useful, but VERY tricky. If you do this (and I think it would be
extremely powerful) please remember that, although things like hide-whens are
not security features on the client, they ARE on web sites. Having a command
like this would potentially bypass this, so it must be configurable (and
default to OFF.)
The transform isn’t so important to me (though I know it is to others) because
I think that kind of thing should be done client-side.
[]DXL Import/Export capability from the Notes Client. Ability to import
from DXL files into document(s), ability to export document(s) to DXL files.
What are your security / usuability concerns? 1+ would be to apply XSL as well,
“E&T” = Export to DXL, Transform, write to file, “T&I” = read from file,
Transform to DXL, Import – how important is the 1+? (Note: XSLT style sheets
for transforms would be user-supplied, not part of N/D.)[]
Why would I need you to do something I can already do with Lotuscript?
[]Ability for all of the Exporter / Importer APIs to easily include
transform(s) – similar to E&T and T&I from previous item. Convenience feature.
You can accomplish the same thing with existing APIs, but with a little more
work because you have to code up the transformer logic yourself.[]
Maybe I’m missing something, but this seems like a low-value add. I can do
this myself already without relevant performance loss. It’s, what, 15 lines of
Lotuscript? If there’s a performance implication, then it’s a different
matter, but I’m talking about the difference between loading an agent context
for every document read, not something like a client-import.
[]HTML generation from DXL: What level of fidelity do you require? 1+
would be to support other formats (e.g. PDF) – how important is the 1+, and to
which formats? Is there alternate format that is more suitable; for example
XSL:FO generation from DXL? (Then use any transforms available in the industry
to go from XSL:FO to HTML et. al.) Are there open source solutions that
eliminate this requirement?[]
Check out these two OpenNTF.org projects for some examples of current transform
techniques:
http://www.openntf.org/Projects/pmt.nsf/ProjectHome?ReadForm&Query=DXLPeek
http://www.openntf.org/Projects/pmt.nsf/ProjectHome?ReadForm&Query=Domino%20Web%
20Tools
Transforms to PDF would generally be great as well. If it were reasonably easy
to, from an URL command, get a Domino document or view as a PDF file, I could
imagine some incredibly powerful applications coming out of that. Good,
customer-facing stuff would be remarkably easy.
[]XSLT Style Sheet design element: Possibly needed to support 2., 3., and
4., and maybe 5., if we want the ability for the XSLT style sheet to come from
the database rather than a filesystem file or elsewhere.[]
I have to find the article I wrote about this a few years back, but that’s
about 50% of what’s needed. What’s REALLY needed is automatic generation of
style sheets from existing design elements! If forms and views could be
accessed as TRANSFORMS, and you combined that with ?ReadDXL and
?ReadViewEntries, and made a simple mechanism for CLIENT-SIDE transforms
according to these rules, then Domino could become the premier platform for
extremely fast, lightweight and versatile web interfaces. You can’t tell me
that it wouldn’t be useful in the Workplace model, either. How much simpler
does the Eclipse client get when you surface those kinds of features?
[]“URL” class in LotusScript and Java: At a minimum, this would work in
conjunction with NotesStream / Stream so that those classes could read a stream
of input data from a URL. Major use would be to get input for XML parsers, DXL
Importer, or XSLT Transformer from URLs.[]
I’d love to have this, but if it’s reliant on the whole server web retriever
stuff that’s needed today, forget it. That stuff is a mess, and it’s FAR too
late for Notes to be an effective browser platform. If it’s purely for
streams, and you aren’t reliant on any of the existing web configuration stuff
for this, so it doesn’t matter what my location settings are or whether it’s
executed from a server, then yeah, it’s a great idea.
[]Import DXL into some sort of a memory object: Instead of directly
creating notes in a database. Pretty sketchy how this would work at this point,
but is it an idea worth pursuing?[]
Minimal value. It’s not like people doing serious DXL work don’t know how to
import into a collection they intend to delete (or even an entire database.)
[]Mechanism to generate LotusScript/Java classes for working with XML:
Idea here would be to take any XML vocabulary (not DXL) and automatically
generate (from its schema) classes with properties and methods that allow one
to work with the XML data in a language-specific way rather than dealing with
the XML directly. Deserialize method would go from XML to objects and serialize
from objects to XML.[]
That sounds REALLY cool. But it also sounds expensive in terms of development
and testing. Also, remember that most LS developers in the real world don’t
write classes. There’s a handful of us that are serious about OO in LS. And
you’d probably need to get the IDE and LS people more seriously involved in
class support, so we can, say, inherit from native classes, and get browsable
user-classes.
[]Provide DXL Exporter capability for transforming notesbitmap to jpeg
and/or png. (Already can do notesbitmap → gif.)[]
shrug We’d be better off with improved capabilities for Images Resources
(such as allowing them to be created directly from files via LS, and then an
ACL setting which allows Authors to generate them.) Then nobody who’s serious
will even use notesbitmaps any more.
[]Implement DXL for features that don’t yet have a high-level
representation in DXL. List includes calendar view, MIME, web service, shared
column, OLE, file resource, style sheet resource, layer, outline, replication
formula, layout regions, database icon, viewentries, navigator. Are any of
these important to you and if so, which few are the most important and how do
they balance against the other features above?[]
Calendar view, MIME, shared columns (these are going to be used A LOT in a post
7 world. You cannot imagine the bottled desire for this feature.) and
replication formulas would top my list. But really, most of these are about
development style. (Ben’s going to want layer representation, for example.) I
wouldn’t bother with anything that’s been really obviously deprecated though
(navigators and layouts)
Hope that’s useful!
Subject: RE: What XML/DXL features would you like to see post-7.0?
Wow. The others were all so brief. (I deliberately answered before reading any other replies.) Don’t I feel like a windbag now?
Subject: The detail is awesome
Write a book! Seriously, the more detail folks can provide, the better.
Subject: Oh, I should also mention…
I should also add that for this idea…
Mechanism to generate LotusScript/Java classes for working with XML:
Idea here would be to take any XML vocabulary (not DXL) and automatically
generate (from its schema) classes with properties and methods that allow one
to work with the XML data in a language-specific way rather than dealing with
the XML directly. Deserialize method would go from XML to objects and serialize
from objects to XML
…to be of value there had BETTER finally be a class browser in Designer!
Subject: RE: What XML/DXL features would you like to see post-7.0?
I want to echo what Nathan says about the URL class. Don’t bother if it is just using the web retriever stuff.
In general, I agree with most of what Nathan says, although in terms of backwards compatibility, I think you probably need to support even Navigators and Layouts, at least at some level. They may not be used a lot, but I have people wind up buying our tools to deal with layout regions in old mail messages (Ray Ozzie comes to mind as a recent example). There is lots of old data out there with layour regions because of how they used to be used, and IBM has always been a strong proponent of supporting older data to ensure people have confidence that IBM will long support current data. For that reason, I think it is worth the development effort.
Subject: RE: What XML/DXL features would you like to see post-7.0?
My thoughts primarily revolve around complimenting/exposing already-existing functionality in ?ReadViewEntries:
#1 - ?ReadViewEntries - “prior entries” and pagination functionality
There is a HUGE portion of functionality missing from ?ReadViewEntries – “prior entries” data.
Consider the following command.:
…?ReadViewEntries&Start=1.1.20&Count=10
If you wanted to grab the prior 10 entries, well… you can’t reliably. You could try to make a guess (e.g. Start=1.1.10), but if you don’t have access to read 1.1.10-1.1.19 then you get stuck with the exact same result set. So how far back do you need to go?
If ?ReadViewEntries would return the “prior page” entry position using the &Count increment you passed, that would be a huge help. The HTTP server already calculates this for HTML-rendered views (it gets glued to the “Previous” button), so the functionality is already there.
Knowing the position of the entries on the “last page” would be helpful – it would provide a way to “jump” to column totals quickly (e.g. in the Java View Applet the equivalent of hitting ctrl-end or dragging the scroll widget to the bottom).
Additional paging information, such as how many entries in the view are visible to the user, would also be helpful but could possibly be a significant performance killer. I actually think, though, that this number is returned somewhere in the XML that gets sent to the Java View Applet – it’s just not documented to us developers.
These pieces of functionality are the only things that stand in the way of presenting Domino view data with all of the navigational functionality of modern web pages, e.g. a navigation bar such as:
<<Previous Page - 1, 2, <3>, 4, … , 27 - Next Page >>
#2 - ?ReadViewEntries - &Expand= supporting multiple arguments
It would be really nice to be able to expand more than one category at once, e.g.:
…?ReadViewEntries&Start=1&Count=10&Expand=1.1,1.4,1.6
#3 - ?ReadViewEntries - enhanced &RestrictToCategory use
As mentioned here: http://www.jackratcliff.com/jratcliff/blog.nsf/dx/RestrictToCategory.htm
#4 - ?ReadViewEntries - argument &StartKey should work with a numeric column
If you use &StartKey on a view where the first sorted column is a numeric value you always get an empty result set. See SPR #BMGN6DVP74 for more details.
#5 - ?SearchViewEntries
I also echo Jack Ratcliff’s request for ?SearchViewEntries features.
On top of these, I 100% agree with absolutely every one of Nathan’s views on the points already listed.
Subject: Possibly partway there… Re:What XML/DXL features would you like to see post-7.0?
Regarding the request for pagination information in ?ReadViewEntries:
If you use ?ReadViewEntries with an &StartKey and &UntilKey parameter, you receive an attribute called “rangeentries” – which appears to be the number of entries to which you have readers access.
Unfortunately there’s two major problems: (1) it’s not documented, and (2) you have to have both a StartKey and UntilKey. Getting a StartKey isn’t too difficult, but an UntilKey is.