[
Lists Home |
Date Index |
Thread Index
]
Hi David,
I understand where you come from with your syntax - I have the same
problem in the database world. But while I may claim my language has
some significant advantages over SQL it is neither a replacement nor a
next generation. It is just different and suits me and my projects. I
think your syntax is basically in the same boat. Using < and > does not
make anything xml, sgml, or html for that matter. It must first conform
to the syntax.
So to get to the point. There are from my perspective (and possibly
others on the list) 2 real disadvantages in your approach.
1. The content of the element has syntax. ie there is a "tag" syntax and
a "content" syntax. For me that's a big disadvantage. I really, really
like the typeless nature of element content. (yes I know there is a
minor syntax in xml elements - elements may contain elements, and CDATA
- but that's it).
2. There's no semantics in your end tag. Back to the "matching brackets"
problem. In high volume automated conversations and document exchanges
this is a real problem for reliability and validation.
Bloatware? No I think java carries all the honours there. Modern parsers
are fast and efficient, as are their XSLT companions.
Top 10 XML issues:
1. Varied browser support - eg xml islands. I can wait for Vista etc but
IE7 released would be significant (hope I didn't miss it)
2. Slow takeup by some programmers (this reflects conservatism and in
some cases laziness mor ethan anything else, because it simply isn't
hard once you get into it).
3. ...
Sorry ran out of issues. XML is, in my view a stable and mature
technology and is now an important technology for all areas of software
development.
Regards
Rick
David Lyon wrote:
>On Mon, 2006-07-24 at 09:26 -0500, Peter Hunsberger wrote:
>
>
>>On 7/24/06, David Lyon <david.lyon@preisshare.net> wrote:
>>
>>
>>>On Mon, 2006-07-24 at 21:15 +1000, Rick Jelliffe wrote:
>>>
>>>
>>>>There is nothing stopping you doing this in real XML, just moving the
>>>>type tag inside the attribute value. For example (off the top of my
>>>>head, details may be wrong):
>>>>
>>>> <Item Information PLU="A256" Name="Kitchen Veneer" Rate="$420"/>
>>>>
>>>>Then you can validate with Schematron, for example
>>>> <sch:pattern name="typedAttribute" abstract="true">
>>>> ...
>>>> <sch:rule context="starts-with($node, '$')">
>>>> <sch:assert test="number(string-after($node, $))"
>>>> >A currency attribute should have a number</sch:assert>
>>>> </sch:rule>
>>>> ...
>>>> </sch:pattern>
>>>>
>>>> <sch:pattern is-a="typedAttribute">
>>>> <sch:param name="node" value="Item/@*"/>
>>>> <sch:pattern>
>>>>
>>>>Cheers
>>>>Rick Jelliffe
>>>>
>>>>
>>>Ok, say I did that.. what do I now get?
>>>
>>>
>>Among other things:
>>
>>1) the ability to use standardized parsers without having to write and
>>maintain your own;
>>
>>2) the ability to use an ISO standard for data validation without
>>having to write and maintain your own;
>>
>>3) compatibility with external systems with no extra transformation
>>requirements (reduced processing overhead).
>>
>>
>>
>
>No, I just end up with a whole lot of bloatware...
>
>
>
>-----------------------------------------------------------------
>The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
>initiative of OASIS <http://www.oasis-open.org>
>
>The list archives are at http://lists.xml.org/archives/xml-dev/
>
>To subscribe or unsubscribe from this list use the subscription
>manager: <http://www.oasis-open.org/mlmanage/index.php>
>
>
>!DSPAM:44c5481c160051896214748!
>
>
>
|
