whilst i agree there is advantage in supporting the use of a ubiquitous
web browser, you give the impression we don't have this ability otherwise.
if you examine the diagram below you will see the example Invoice
instance (collapsed down to the highest meaningful level) as shown in
Internet Explorer.
[invoice-nolist-view.jpg]
this reflects the current schemas we are producing without any list
containers.
the next diagram shows the same view with the same instance using the
'all lists' schema...
[invoice-list-view.jpg]
- if we click on the <in:InvoiceLineList> "+" we get the following view...
[invoice-list-lines-view.jpg]
This demonstrates the comparitive differences we are discussing. How
much advantage does the extra level give us? I don't want anyone to
think using list conatiners is the only way to benefit from a folding
editor/XML view. both strategies enable us to expand and collapse -
lists just give us additional layers.
wrote:
>| In section 6, you mention readability. If you read XML documents
>| using Notepad or vi, container elements do not help readability.
>| However, if you use a folding XML editor/viewer, even Internet
>| Explorer, containers are great for folding up a repeated group of
>| elements that you do not want to look at. You do not need
>| hundreds, nor even thousands, of items for this to be true.
>
>This is a *huge* UI advantage. Giving every user the ability to
>open a big UBL instance in a ubiquitous web browser and
>collapse/expand to find her way around is enough all by itself to
>make a case for containers.
>
>Jon
>
>
>
--
regards
tim mcgrath
phone: +618 93352228
postal: po box 1289 fremantle western australia 6160
