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

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

Hi David,

It should be ns1:root/a/b/ns2:root/b as Philip says because in the scheme I 
described a and b were unqualified.  As such there's no difference in name 
between b in ns1 and b in ns2 as there would be if they were qualified.

I think Philip is right about the issues.  It's down to the limitations in 
XPath expressibility.  You need to say something like: b whose qualified 
parent is in namespace ns1.  Sort of   b[qualified-parent-ns()=ns1]!

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: "David" <dlee@calldei.com>
To: <xml-dev@lists.xml.org>
Sent: Thursday, October 28, 2010 1:51 PM
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