Re: [xml-dev] Venetian Blinds vs Garden of Eden patterns for industry st

["Pete Cordell" <petexmldev@codalogic.com>]

Original Message From: "Philip Fennell"

> May be I'm wrong but I'd interpreted Pete's example:...

My scenario was more applicable when you use XML directly in Java, C# and 
C++ perhaps via DOM or various stream readers etc.  For someone for who XML 
is a means to an end rather than a way of life, saying "put this funny 
prefix on the first element, and the odd attribute in the start and then you 
don't have to worry about XML namespaces anymore" seems like a big win.

The problem with the approach comes when you want to access parts of it 
using XPath.  For many people using XPath isn't necessary and for others it 
is.  XPath could have been defined with an operator of b[context()=ns1], but 
it hasn't.  Even if you don't think people will want to use XPath with your 
XML, it's a brave person that designs a schema that disregards the XPath 
issue.

I hope that makes sense!

Pete Cordell
Codalogic Ltd
Interface XML to C++ the easy way using C++ XML
data binding to convert XSD schemas to C++ classes.
Visit http://codalogic.com/lmx/ or http://www.xml2cpp.com
for more info
----- Original Message ----- 
From: "Philip Fennell" <Philip.Fennell@marklogic.com>
To: "David" <dlee@calldei.com>; <xml-dev@lists.xml.org>
Sent: Thursday, October 28, 2010 3:20 PM
Subject: RE: [xml-dev] Venetian Blinds vs Garden of Eden patterns for 
industry standards XML Schemas



May be I'm wrong but I'd interpreted Pete's example:

<myNS:root xmlns:myNS="abc">
      <element1>
          <elementWithTypeDefinedInAnotherNamespace>
          </elementWithTypeDefinedInAnotherNamespace>
      </element1>
</myNS>

as allowing people to write shorthand XPaths thus:

myNS:root/element1/elementelementWithTypeDefinedInAnotherNamespace

Which is all well and good when you have an absolute path because you can 
see the context, but as soon as you start chopping up that path you need to 
re-attach the context.

Now, from an application's perspective, that understands this form, the 
above example resolves to:

myNS:root/myNS:element1/myNS:elementWithTypeDefinedInAnotherNamespace

and you could probably write that in an XSLT transform and it'd mean the 
same as my original example. The problem is that you've got two ways of 
affectively saying the same thing and as you start using XPaths that start 
at some point lower in the location path you'll need to re-assert the 
context thus:

myNS:elementWithTypeDefinedInAnotherNamespace

and that's not what I originally wrote using Pete's short-hand:

elementWithTypeDefinedInAnotherNamespace

Therefore I feel that this is inconsistent, therefore potentially ambiguous 
and could lead to confusion and error.

If I've misinterpreted Pete's example then may be some one could help me 
out. Pete, did I interpret your example correctly?


Regards

Philip Fennell
Consultant
MarkLogic Corporation
Mobile +44 (0) 7824 830 866
email  Philip.Fennell@marklogic.com
web    www.marklogic.com

This e-mail and any accompanying attachments are confidential. The 
information is intended solely for the use of the individual to whom it is 
addressed. Any review, disclosure, copying, distribution, or use of this 
e-mail communication by others is strictly prohibited. If you are not the 
intended recipient, please notify us immediately by returning this message 
to the sender and delete all copies. Thank you for your cooperation.






________________________________________
From: David [dlee@calldei.com]
Sent: 28 October 2010 13:51
To: xml-dev@lists.xml.org
Subject: Re: [xml-dev] Venetian Blinds vs Garden of Eden patterns for 
industry standards XML Schemas

I guess I still dont get the problem.
Wouldn't you just do

ns1:root/ns1:a/ns1:b/ns2:root/ns2:b

and be done with it ?


But thats ok I dont have to "get it"  :)


David A. Lee
dlee@calldei.com
http://www.xmlsh.org


On 10/28/2010 8:40 AM, Philip Fennell wrote:
> David wrote:
>
>> I dont get this last bit, could you expound please ?
> I was extrapolating from Pete's example with the 'context' wrapper for a 
> namespaced fragement that a compound XML document that used the 'context' 
> method of binding namespaces to fragments would make transforming such a 
> document very difficult because you could end up with XPath select 
> expressions that looked like this:
>
> ns1:root/a/b/ns2:root/b
>
> and where you night be using a template match on b you'd have to then 
> qualify that match with the appropriate namespace prefix which wouldn't 
> look like the path you used in the select. I just think it'd be much 
> harder to read. May be a little less to type but it'd be more ambiguous.
>
> Regards
>
> Philip Fennell
> Consultant
> MarkLogic Corporation
> Mobile +44 (0) 7824 830 866
> email  Philip.Fennell@marklogic.com
> web    www.marklogic.com
>
> This e-mail and any accompanying attachments are confidential. The 
> information is intended solely for the use of the individual to whom it is 
> addressed. Any review, disclosure, copying, distribution, or use of this 
> e-mail communication by others is strictly prohibited. If you are not the 
> intended recipient, please notify us immediately by returning this message 
> to the sender and delete all copies. Thank you for your cooperation.
>
>
> ________________________________________
> From: David [dlee@calldei.com]
> Sent: 28 October 2010 13:16
> To: xml-dev@lists.xml.org
> Subject: Re: [xml-dev] Venetian Blinds vs Garden of Eden patterns for 
> industry standards XML Schemas
>
> I dont get this last bit, could you expound please ?
>
> "Within an XSLT transform that'd be a nightmare."
>
> In XSLT or XQuery the namespace is on every node reguardless of if its 
> physically there in the text representation.  So why does it matter if the 
> text representation has more or less of them ?
> You can extract fragments of a complex multi-namespace tree and the output 
> result will properly add the required namespaces to disambiguate the 
> results.
>
>
>
> David A. Lee
> dlee@calldei.com
> http://www.xmlsh.org
>
>
> On 10/28/2010 7:59 AM, Philip Fennell wrote:
>> Pete wrote:
>>
>>> That way you only ever have one namespace declaration (ignoring QName
>>> issues) irrespective of the types you use from other namespaces, and you
>>> only have the root element as qualified.  So your XML instance looks 
>>> like:
>>> <myNS:root xmlns:myNS="abc">
>>>       <element1>
>>>           <elementWithTypeDefinedInAnotherNamespace>
>>>           </elementWithTypeDefinedInAnotherNamespace>
>>>       </element1>
>>> </myNS>
>>> The instance is appropriately tagged with it's namespace, but it's all
>>> clearly done in one place and there's no other namespace gotchas to 
>>> worry
>>> about.
>> I think I see what your trying to do but surely with the above approach 
>> you are going to have problems when processing fragments of the document 
>> because you'll lose the context if the fragments are taken as-is. I 
>> presume, to counter that you're talking about having the 'context' or 
>> 'root' wrapper being used to contain any fragment of the document which 
>> means that the container element's content model must allow all possible 
>> elements, from the schema, as children (or may be a defined sub-set of 
>> all). In more complex compound documents (XHTML + XForms or XSLT + XHTML 
>> + XForms) that'd introduce a lot of noise into the document and add a 
>> different kind of complexity where you're switching namespaces more 
>> frequently as you traverse the tree in and out of context wrappers. From 
>> a readability point of view you'd be constantly having to scan back up 
>> the tree to get you namespace context. Within an XSLT transform that'd be 
>> a nightmare.
>>
>> Regards
>>
>> Philip Fennell
>> Consultant
>> MarkLogic Corporation
>> Mobile +44 (0) 7824 830 866
>> email  Philip.Fennell@marklogic.com
>> web    www.marklogic.com
>>
>> This e-mail and any accompanying attachments are confidential. The 
>> information is intended solely for the use of the individual to whom it 
>> is addressed. Any review, disclosure, copying, distribution, or use of 
>> this e-mail communication by others is strictly prohibited. If you are 
>> not the intended recipient, please notify us immediately by returning 
>> this message to the sender and delete all copies. Thank you for your 
>> cooperation.
>>
>>
>>
>>
>>
>> ________________________________________
>> From: Pete Cordell [petexmldev@codalogic.com]
>> Sent: 28 October 2010 11:16
>> To: xml-dev@lists.xml.org
>> Subject: Re: [xml-dev] Venetian Blinds vs Garden of Eden patterns for 
>> industry standards XML Schemas
>>
>> One thing I'm surprised is not more popular is to always use Venetian 
>> Blind,
>> even across namespaces, BUT make local elements unqualified, i.e. use
>> elementFormDefault="unqualified".
>>
>> That way you only ever have one namespace declaration (ignoring QName
>> issues) irrespective of the types you use from other namespaces, and you
>> only have the root element as qualified.  So your XML instance looks 
>> like:
>>
>> <myNS:root xmlns:myNS="abc">
>>       <element1>
>>           <elementWithTypeDefinedInAnotherNamespace>
>>           </elementWithTypeDefinedInAnotherNamespace>
>>       </element1>
>> </myNS>
>>
>> The instance is appropriately tagged with it's namespace, but it's all
>> clearly done in one place and there's no other namespace gotchas to worry
>> about.
>>
>> The approach mirrors JSON's response to "there's nothing like XML 
>> namespaces
>> in JSON."
>>
>> I think the issue is that the interpretation of a element depends on the
>> context provided by the parent and XSLT and other XPath technologies have
>> difficulty with that.
>>
>> Spot the outsider!
>>
>> Pete Cordell
>> Codalogic Ltd
>> Interface XML to C++ the easy way using C++ XML
>> data binding to convert XSD schemas to C++ classes.
>> Visit http://codalogic.com/lmx/ or http://www.xml2cpp.com
>> for more info
>> ----- Original Message -----
>> From: "Pete Cordell"<petexmldev@codalogic.com>
>> To:<xml-dev@lists.xml.org>
>> Sent: Thursday, October 28, 2010 10:58 AM
>> Subject: Re: [xml-dev] Venetian Blinds vs Garden of Eden patterns for
>> industry standards XML Schemas
>>
>>
>>> FWIW I would use:
>>>
>>> <xs:element name="" type=""/>
>>>
>>> (i.e. Venetian Blind) where type is within the same namespace/schema as
>>> the element, and:
>>>
>>> <xs:element ref=""/>
>>>
>>> (i.e. Salami Slice) when the element(/type) being accessed is in a
>>> different namespace.
>>>
>>> To give it a name I'll call it Venetian Slice!
>>>
>>> By analogy to a class interface, I see the global elements as the public
>>> members of an interface, and the global types as the private members. 
>>> The
>>> interface should only publically expose what it has to, and Venetian 
>>> Blind
>>> provides a non-narrative way to express that.  Accessing a new namespace
>>> is analogous to accessing a new class, and so the public interface (i.e.
>>> global elements) of that namespace have to be used.
>>>
>>> That should open up the discussion!
>>>
>>> Pete Cordell
>>> Codalogic Ltd
>>> Interface XML to C++ the easy way using C++ XML
>>> data binding to convert XSD schemas to C++ classes.
>>> Visit http://codalogic.com/lmx/ or http://www.xml2cpp.com
>>> for more info
>>> ----- Original Message -----
>>> From: "Dennis Sosnoski"<dms@sosnoski.com>
>>> To:<xml-dev@lists.xml.org>
>>> Sent: Thursday, October 28, 2010 6:41 AM
>>> Subject: Re: [xml-dev] Venetian Blinds vs Garden of Eden patterns for
>>> industry standards XML Schemas
>>>
>>>
>>>> If you're thinking of using data binding for working with the data in
>>>> applications I'd strongly recommend a Venetian Blinds approach. Most
>>>> data binding approaches turn Garden of Eden into an amorphous foam of
>>>> tiny classes - which is, after all, exactly what Garden of Eden
>>>> represents in XML terms.
>>>>
>>>> Associating the name "Garden of Eden" with this concept of pureed
>>>> structure was excellent marketing, but doesn't really give the right
>>>> impression. I'd suggest "Element Soup" as an alternative. :-)
>>>>
>>>>    - Dennis
>>>>
>>>>
>>>> On 10/28/2010 05:31 AM, Lech Rzedzicki wrote:
>>>>> Hi all.
>>>>>
>>>>> I am now involved in developing the next iteration of schemas to
>>>>> standardise information storage and exchange for trademarks and design
>>>>> (there is also some cooperation with patent people).
>>>>> The current standards (TM-XML and DS-XML) use a venetian blind pattern
>>>>> because it nicely mimics OO model, so it's easy to generate classes
>>>>> and objects, also it hides element definitions so there's no conflicts
>>>>> when processing them. Finally the naming convention (not my idea)
>>>>> means that the element names are not reusable anyway.
>>>>> Some people are now proposing that we move to "Garden of Eden" design
>>>>> patter, but I don't see that as a particularly smart move in the
>>>>> context of our domain.
>>>>> I have noticed that many of the schemas in the industry, for instance
>>>>> UBL have gone for Garden of Eden first and and later reverted to
>>>>> Venetian Blinds.
>>>>> I am very interested in some thoughts from the trenches as to why one
>>>>> or the other approach might be more useful in a committee driven
>>>>> standards with contributors from different domains.
>>>>>
>>>>> No need to point me to google either - I have read all the articles
>>>>> about it [1,2,3] and authored schemas that are in production now both
>>>>> ways, but still unconvinced either way...
>>>>>
>>>>>
>>>>> References:
>>>>>
>>>>> [1] A slideshows on various approaches:
>>>>> http://dret.net/lectures/xml-fall08/xsd-2#(11)
>>>>> [2] http://www.xfront.com/GlobalVersusLocal.html - schema best 
>>>>> practices
>>>>> [3] http://www.ibm.com/developerworks/xml/library/x-schemascope/
>>>>> etc...
>>>>>
>>>>> _______________________________________________________________________
>>>>>
>>>>> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
>>>>> to support XML implementation and development. To minimize
>>>>> spam in the archives, you must subscribe before posting.
>>>>>
>>>>> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
>>>>> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
>>>>> subscribe: xml-dev-subscribe@lists.xml.org
>>>>> List archive: http://lists.xml.org/archives/xml-dev/
>>>>> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>>>>>
>>>>>
>>>> _______________________________________________________________________
>>>>
>>>> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
>>>> to support XML implementation and development. To minimize
>>>> spam in the archives, you must subscribe before posting.
>>>>
>>>> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
>>>> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
>>>> subscribe: xml-dev-subscribe@lists.xml.org
>>>> List archive: http://lists.xml.org/archives/xml-dev/
>>>> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>>>>
>>>>
>>
>>
>> _______________________________________________________________________
>>
>> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
>> to support XML implementation and development. To minimize
>> spam in the archives, you must subscribe before posting.
>>
>> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
>> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
>> subscribe: xml-dev-subscribe@lists.xml.org
>> List archive: http://lists.xml.org/archives/xml-dev/
>> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>> _______________________________________________________________________
>>
>> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
>> to support XML implementation and development. To minimize
>> spam in the archives, you must subscribe before posting.
>>
>> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
>> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
>> subscribe: xml-dev-subscribe@lists.xml.org
>> List archive: http://lists.xml.org/archives/xml-dev/
>> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>>
>
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>


_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php