[Dev] XML for CPIA

[John Anderson]

Alec Flett wrote:

> John Anderson wrote:
>
>> I'd prefer a single format that works for all kinds of repository 
>> data, not just CPIA blocks. If I were going to optimize editing and 
>> construction of CPIA blocks, I'd much prefer a GUI builder to yet 
>> another XML format. 
>
> Fair enough. Show me a GUI builder and I'll stop pushing for a 
> declarative format for the UI.

Based on the amount of time we spent on parcel XML, I suspect that if 
the amount of work to build/maintain yet another XML format is not much 
different from the amount of work to build a simple GUI builder, and I 
think the GUI builder has a bigger payoff.

>
> But the thing is, we've always had a single format for all kinds of 
> repository data  - you could always declare any instance in Python. 
> pje's just made it easier. It doesn't mean there aren't more 
> appropriate means for specific types of items, like the UI.
>
>> Having a way to "compile" and "decompile" repository data would be a 
>> useful if we had a GUI builder, but it would be much more useful if 
>> the format it used was familiar -- after all look how many people 
>> took the time to understand andi's pack XML format.
>>
> Woah, lets get some context here. Andi's pack format is for defining 
> low level relationships between data types in the repository . This is 
> a hierarchical tree of UI, which is in fact the original purpose of 
> SGML/HTML, which is the inspiration for XML. This is a VERY common 
> idiom in toolkits. Your argument seems to be "anything in xml is hard 
> to learn"?

Actually, it's not that XML is hard to learn, it's learning the concepts 
you need to encode in XML (e.g. CPIA) and how they map to XML.

>
> Think of it this way: you can instantiate wx widgets anytime in C or 
> Python, and yet we use the xrc format for our dialog boxes, because 
> writing that in python is a big pain in the neck. pje's .update 
> mechanism is obviously a vast improvement, but its still not 
> appropriate for the UI.

Almost nobody uses xrc directly, it's the format that is edited by the 
GUI tools.

>> Finally, Python would probably load faster than XML, produce better 
>> error messages, require less maintenance, and be more flexible than 
>> yet another XML format.
>>
> ok...lets break it down.
> Speed: we're talking milliseconds. If that's an issue, we shouldn't be 
> using python at all.
> Error messages: How do you figure? Are python syntax exceptions easier 
> to read than error messages that come from a parser that understands 
> the purpose and context of the data it is reading?

Regarding errors, I've spent much more time trying to figure out Parcel 
XML errors than I ever spend figuring out python errors. Usually this is 
due to the limitations of parsing XML with tools we use -- they just 
don't give you the same granularity as the Python compiler. I can't tell 
you the number of times I've gotten the parcel XML message that say 
nothing useful, or the number of times I've had to comment out the 
parcel XML exception handler to figure out where the error really occurred.

> Flexibility: That isn't a goal of this format. parcel.xml is pretty 
> darn flexible, and yet it sucks and we're moving away from it.

>
> I feel like folks are leaning towards pje's python .update mechanism 
> as the GUT of item declaration.. and I think that's a mistake and I 
> think its because people feel burned by parcel.xml. Its the underlying 
> API sure, but if we never HAD parcel.xml, I can guarantee you that I 
> wouldn't be the first one to say ".update() is really tedious for the 
> UI - lets find a simpler way to declare this stuff.. what about xml?"
>
> Alec
>
>> John
>>
>> Bryan Stearns wrote:
>>
>>> I don't see why this is necessary:
>>> - It's another syntax to learn, but who'll learn it?  Most parcel 
>>> developers who are adding item types will mostly just be writing 
>>> detail-view trees of blocks; I'm looking forward to rewriting the 
>>> detail view's parcel.xml as Python, so the ready examples that 
>>> developers will have will be Python. Few non-Python developers will 
>>> be customizing other parts of the UI, at least in the next year or so.
>>> - The syntax isn't better: while it might be familiar to HTML 
>>> programmers just because it's XML, it isn't simpler or terser than 
>>> the equivalent Python code given in the example.
>>>
>>> (and what's with the "<ref: 22d5dbf0-0921-11da-ab3d-00054e47c157>"?)
>>>
>>> ...Bryan
>>>
>>>
>>> Alec Flett wrote:
>>>
>>>> Here's a very quick overview of my XmlForCpia proposal. I have 
>>>> already implemented the parser that does all of these things, as 
>>>> well as a tool that dumps the current block structure from a 
>>>> currently-running chandler into XmlForCpia format (in fact that's 
>>>> where the same code comes from)
>>>
>>>
>>>------------------------------------------------------------------------
>>>
>>>_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>>
>>>Open Source Applications Foundation "Dev" mailing list
>>>  
>>>
>>
>>>http://lists.osafoundation.org/mailman/listinfo/dev
>>>  
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/dev/attachments/20050810/27824ba5/attachment.html