Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XLink: behavior must go!
Martin Bryan <mtbryan@s...> wrote:
>I wrote:
>>you can use an industry-standard DTD to good effect - it is just that
>the industry in question isn't "the XML industry"; instead it might be "the
>XML browsing industry", and the standard isn't "XML", it is "XML as used in
>browsers". There's simply no way a browser will be able to correctly handle
>links whose behavior is specific to vlsi design process, unless someone
>explicitly codes a stylesheet which explains how to do so.
>
>The problem I am trying to deal with is not related to "the XML industry"
or
>"the XML browser industry" - instead it relates to a set of DTDs that share
>common-features which apply to a wide range of applications shared by a
wide
>range of industries. If we are to develop sharable toolsets we need to
>develop sharable architectures.
IMVHO, the problem is more with the lack of power in current DTDs. If it
were possible to reuse DTD fragments, for example, containing the
functionality you want, then the problem would have been solved. Moving the
shared functionality directly into the XML standard works around this
limitation, but I feel it is the wrong thing to do.
>The key point is that I want, in the longer
>term, to replace the current practice of relentlessly copying data from one
>message to another (up to 10 times in some processes) with a process that
>allows linking to the original source of the data.
That's a good goal, I don't have any problem with it.
>The way this will be done
>will depend on the type of the data being linked to and on the local
>conditions for access to original documents. OK, I can define a generalized
>architecture that would be widely used for this purpose, and call it
>edi:behaviour, but as this is widely required by others why not also have
it
>as a standard mechanism for passing link instance dependent information to
>the link processor?
If you can define a set of behaviors and make a good case that this set is
applicable to the vast mojority of XML applications, they I'll gladly join
you in lobbying for adding an 'xml:behavior' attribute to XLink with this
set of values. In fact, I'm all for releasing XLink without a behavior
attribute and creating a WG (or maybe placing it within the XLink WG
mandate, whetever) dedicated to this attribute.
IMVHO, we won't have a sensible notion of what to place in such an attribute
until people will have some experience using XLink. Which means we'll have a
year or so of 'my:behavior' and 'your:behavior'. After this year we'll see
what is really common behavor, and release XLink 2.0 with 'xml:behavior'
covering these cases.
But even in this case, it should still be possible to add behaviors outside
this set - 'my:behavior' will never disappear, even assuming the current
specs. Actually, I can even accept 'behavior' as it stands today provided
the specs say that this attribute is reserved, its valid set of values will
be defined in a future version of the draft - effectively meaning that
'xml:behavior' has the priviliege of being called simply 'behavior'.
Actually if there is one or two behaviors on which the WG could agree
_today_, such as "include as an XML fragment within this document", then by
all means release them in version 1.0. But release it! waiting another year
for this issue to be resolved only harms the proposal.
>It should not be necessary to have individual
>stylesheets for individual instances of messages.
>It should not be necessary
>to redefine processes for each DTD that uses the shared information.
Agreed; why do these follow from what Paul (and I) propose?
>We need
>to import standardized modules that will process standardized namespaces of
>elements in ways that depend on the conditions applying at the point at
>which the located data is to be retrieved from.
The 'behavior' attribute as it is specified - or should I say, unspecified -
today, does not give you this power. As long as it doesn't have a set of
well-defined valid values, it is wores then useless.
Have fun,
Oren Ben-Kiki
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
