OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

tag message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [tag] Namespaces


 Stephen: inline

-jacques


-----Original Message-----
From: stephengreenubl@gmail.com [
mailto:stephengreenubl@gmail.com] On Behalf Of Stephen Green
Sent: Monday, August 24, 2009 12:28 PM
To: TAG TC
Subject: [tag] Namespaces

Are we happy with including namespaces in the drafts of the TAML schema? It could mean we end up with lots of draft namespaces which could confuse. Should we use a different format for our draft schema namespaces?

<JD> I think we should include namespaces as you did.

Also, are we happy including a date in the final namespace?
Some object to doing  this, though it does, I think, comply with OASIS guidelines and precedent.

<JD> I guess over time the date is an intuitive way to track upgrades over the long term. There seems to be many precedents.



There is a related issue of the need to include perhaps even at this early stage a version strategy for our markup. Will we rely on namespace changes?

<JD> I 'd say if the upgrade does not break backward compatibility (i.e. processors for new schema can still process old instances) then we should not change the namespace when versioning.

Will we keep the same namespace for minor changes (those which are backward compatible with the previous schema) and maybe add a version attribute to the top level element?

<JD> yes

Will we also include some kind of 'extension point' (typically an 'xs:any'
element somewhere in the XML structure) to allow us to add future new elements without breaking compatibility with our current version?

<JD> not sure there would be real value in doing this: it could in fact backfire if old processors can digest new instances thanks to extensibility points, yet are unable to actually process these extensions?

The same could be used to add custom elements by others if we wanted to allow this - or we could might think of having two extension points, one for our use (if we keep the same namespace in future minor versions) and one for other, custom, namespaces.
---
Stephen D Green

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]