[brailleblaster] Re: Different Approaches to document processing.
- From: Keith Creasy <kcreasy@xxxxxxx>
- To: "brailleblaster@xxxxxxxxxxxxx" <brailleblaster@xxxxxxxxxxxxx>
- Date: Thu, 3 Jan 2013 16:30:18 +0000
Right, I agree.
Keith Creasy
Software Developer
American Printing House for the Blind
KCreasy@xxxxxxx
Phone: 502.895.2405
Skype: keith537
-----Original Message-----
From: brailleblaster-bounce@xxxxxxxxxxxxx
[mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of Michael Whapples
Sent: Thursday, January 03, 2013 11:22 AM
To: brailleblaster@xxxxxxxxxxxxx
Subject: [brailleblaster] Re: Different Approaches to document processing.
Yes, OK, may be a tree view would have its uses, but still it should only
relate to document concepts not format tags and attributes. Its just when the
term "XML editor" is used then I think of something to edit the actual tags and
attributes present in the file.
Michael Whapples
On 03/01/2013 16:16, Keith Creasy wrote:
> Understood Michael.
>
> I actually think a tree view would be a great addition to BrailleBlaster. Not
> for XML editing exactly but rather to make jumping to specific points in the
> document. No one need understand that it represents an XML tree, it's just a
> way to move to different headings, tables, lists, etc. I have even invisioned
> a way to switch it so that it could show only headings or only images for
> example.
>
> For the rest, I agree that regular users don't need to see actual XML tags
> and attributes unless they specifically want to do that.
>
> Keith Creasy
> Software Developer
> American Printing House for the Blind
> KCreasy@xxxxxxx
> Phone: 502.895.2405
> Skype: keith537
>
>
> -----Original Message-----
> From: brailleblaster-bounce@xxxxxxxxxxxxx
> [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of Michael
> Whapples
> Sent: Thursday, January 03, 2013 10:20 AM
> To: brailleblaster@xxxxxxxxxxxxx
> Subject: [brailleblaster] Re: Different Approaches to document processing.
>
> OK, I think an example of where precision of terms might be useful. When I
> said XML editor, I meant an editor where the user is dealing with the XML
> format directly, either by typing actual XML, viewing it in a treeview, or
> some other representation.
>
> The type of editor I feel BrailleBlaster should have is a WYSIWYG editor, it
> should almost be like using something like Wordpad, OpenOffice, Word...
> insert your favourite WYSIWYG word processor.
>
> The above also goes with what I was saying about the document interface, the
> user should only think about inserting a new column in a table, not that they
> need to add an additional td element to each tr element inside a table
> element, if they are dealing with HTML, could very well be different for
> other formats.
>
> Other design patterns, well the adaptor patternn seems relevant if going with
> my idea that there is a single document interface, we need something to adapt
> between actions done to the standard document interface and the specific
> format. Also such an approach might mean that non-XML formats could be
> handled (although it might lead to interesting things for how to handle UTDML
> on those formats). The factory pattern could very well be useful for getting
> the correct adaptor for a particular format. The observer pattern might be
> relevant for letting the views know that the document has changed and that
> they need to be updated. I think I have seen quite a lot of static stuff in
> the code, should that really be static or might singletons be better? I think
> probably the singletons.
>
> There probably are other design patterns which may be relevant/useful, the
> above are just a few which come to mind.
>
> I also have concerns over whether there is sufficient separation of concerns
> and attempts to maximise reuse. Certainly the reuse one is something I have
> raised in the past as I feel liblouisutdml and BrailleBlaster are both trying
> to do the same thing and so leading to duplication, but those concerns were
> put to one side as reuse was said to not be a concern worth persuing. I would
> need to look back through the list archive to find out what specific process
> was being duplicated, although memory is saying it might be in the area of
> document handling and knowing how to process certain file formats as semantic
> actions are for the file format.
>
> Michael Whapples
> On 03/01/2013 14:50, Keith Creasy wrote:
>> Michael.
>>
>> What other design patterns/practices do you think we should consider?
>>
>> Yes, I agree 100% that whenever possible we should use established
>> mainstream design practices and standards, like MVC CSS, and XSLT, because a
>> lot of developers already know and understand them.
>>
>> About XML editing, don't confuse the term XML Editor" with something that
>> has to be complicated and technical. It can still be fairly simple. Also,
>> I've always felt that it should be something that doesn't have to be used by
>> people who just want to write and print braille. Since we are editing XML
>> (UTDML) then one could posit that BrailleBlaster is an XML editor whether it
>> appears that way or not to users.
>>
>>
>> Keith Creasy
>> Software Developer
>> American Printing House for the Blind KCreasy@xxxxxxx
>> Phone: 502.895.2405
>> Skype: keith537
>>
>>
>> -----Original Message-----
>> From: brailleblaster-bounce@xxxxxxxxxxxxx
>> [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of Michael
>> Whapples
>> Sent: Thursday, January 03, 2013 9:36 AM
>> To: brailleblaster@xxxxxxxxxxxxx
>> Subject: [brailleblaster] Re: Different Approaches to document processing.
>>
>> Hello,
>> I have had some concerns over the design of BrailleBlaster for a little bit,
>> that is partly why I decided to keep away from dealing in the code too much
>> and restrict myself to managing the project site and repositories.
>>
>> Keith I know you mentioned about MVC, yes that probably would be a good
>> idea, but may be BrailleBlaster needs to make use of other design patterns
>> and other good practice as well. By neglecting these things its probably
>> made the code and design much harder to follow and means that where one
>> might use standard terms these might not apply or may even have a different
>> meaning and so leading to miscommunications.
>>
>> Regarding the use of semantic actions, I would dispute the arguement that
>> they are easier to use than XSL. My reasoning here again goes along the line
>> of using something familiar to people, XSLT is widely used and so potential
>> developers may already be familiar with it, should one have a difficulty in
>> making it do what they need then it is much more likely they will find an
>> answer (even if the answer is "not possible") by searching the internet as
>> there is much more information out there on XSLT.
>>
>> Keith you mention about defining a document interface, yes this is something
>> I have felt for some time, the view should have no need to understand the
>> underlying document format, it should deal with a single document interface
>> which through various adaptors/providers will modify the document in the
>> appropriate way. As an example, the view should only deal with headings, it
>> should not be concerned with how HTML or DocX store a heading.
>>
>> My understanding at present is that the semantic actions miss out the
>> document interface stage, mapping straight from a file format to how they
>> should be presented. This step really should be split, actions for adapting
>> the format into the document interface and actions for how the view will
>> render the document structure element. The former of these would not need to
>> be customisable by users (only developers who want to add support for
>> additional formats need work with it), whereas the latter would be desirable
>> to be customised by users (eg. sighted users may want headings shown in a
>> different colour, but those who are colour blind may wish to configure it so
>> that headings can be distinguished without the use of colour). If one does
>> not separate these concerns then users may need to deal with every file
>> format they wish to use, meaning additional work for the user and
>> potentially requiring them to have fairly advanced knowledge we really
>> should not expect of users.
>>
>> As for whether BrailleBlaster should have a XML editor, my view would be
>> not. Such an editor would be contrary to the initial aims of BrailleBlaster
>> being easy to use by those with little computer knowledge (IE. not expect
>> more knowledge than knowing how to use a word processor like Word), as an
>> XML editor would require understanding of the underlying XML format. As
>> mentioned, if someone wishes to have such an editor then there are probably
>> other tools more suited for doing that XML editing.
>>
>> Also I feel by spending time on features not really adding to what
>> BrailleBlaster is aimed to achieve will just delay BrailleBlaster ever
>> reaching the goal of what we want it to be.
>>
>> I know some may feel I possibly have a restricted view of what
>> BrailleBlaster should be, my response is that I feel keep it focused to do a
>> particular task for a particular type of user and do that very well. If one
>> tries to make something which is everything for everyone, then it runs the
>> risk of actually not working well for anyone (IE. its too complicated for
>> beginners and have annoying features for experts).
>> There is certainly some software I can think of which falls in the category
>> of trying to be everything to everyone but not working well for anyone,
>> where competing products while more restricted work far better.
>>
>> There possibly is more, but I possibly have raised it in the past with
>> little affect. So in that spirit, I have pretty well said what I feel,
>> unless further discussion would go anywhere I don't really have much apitite
>> to get into big discussions now. In general I think Keith is making some
>> reasonable points.
>>
>> Michael Whapples
>> On 03/01/2013 12:45, Keith Creasy wrote:
>>> Yes, I've read the comments in the code and your architecture file. Very
>>> helpful.
>>>
>>> We need to work on the interface between the views and the document. That
>>> probably means defining a document interface and a view interface that is
>>> XML centric.
>>>
>>> John, I'm not sure what anyone else can contribute since you want control
>>> of the word processor and the document model. Until those are fleshed out
>>> there's not really much anyone else can do. At least, speaking for myself,
>>> I can't think of anything substantive I can contribute.
>>>
>>> I'm beginning to think that an XML editor really has no place here. Anyone
>>> can just use an external XML editor if they need to do that.
>>>
>>>
>>>
>>>
>>>
>>> Keith Creasy
>>> Software Developer
>>> American Printing House for the Blind KCreasy@xxxxxxx
>>> Phone: 502.895.2405
>>> Skype: keith537
>>>
>>> -----Original Message-----
>>> From: brailleblaster-bounce@xxxxxxxxxxxxx
>>> [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of John J.
>>> Boyer
>>> Sent: Thursday, January 03, 2013 1:50 AM
>>> To: brailleblaster@xxxxxxxxxxxxx
>>> Subject: [brailleblaster] Different Approaches to document processing.
>>>
>>> Hi Keith,
>>>
>>> Yes. Please do outoline your approach. There may be some here who are not
>>> acvaquaintged with it. My approach is described in detail in the files in
>>> the documentation directory of the brailleblaster.newdesign repository. In
>>> addition, Semantics.java contains considerable documentation in the form of
>>> javadoc comments.
>>>
>>> Thanks,
>>> John
>>>
>>> --
>>> John J. Boyer; President, Chief Software Developer Abilitiessoft, Inc.
>>> http://www.abilitiessoft.com
>>> Madison, Wisconsin USA
>>> Developing software for people with disabilities
>>>
>>>
>>>
>>
>
>
>
Other related posts:
